>>Interesting point. I generally assume that any form that is expected to return or set a value probably "should" be modal, because if it is not, you gotta do a lot of hand-waving and peeking and poking to see what has been happening in the "secondary" form. In that case, I suppose one might as well turn on some actual event handling for a cleaner process.
>
>If you want a modeless form to return a value, then the passing of an object with properties to hold the values works very well. But the object has to exist globally at the calling program to the modeless form. In this case setup an event and bind a UDF to it. Then in the modeless form, raise the event when returning. You also need to take care to remove the modeless form if the calling form/procedure ends (nothing to return to...).

Global object? What travesty! (Or at least that's what a purist OOP architect would say)

If you pass an object as a paramater (by reference, which in procedure calls is the default, anyways), why do need to worry about making it global? As long as the receiving form gets the object reference, it has full access to it, and any changes made to it in the called form are reflected in the object in the calling form.

For example:

1. Call a form from another form with the calling form's call button as a parameter:
Button click:

DO FORM AnotherForm WITH This

2. Called form receives and can manipulate the calling button (and any other objects in the calling form at least within the INIT -method):
Form Init:

LPARAM toCallingButton
toCallingButton.Visible = .F.
toCallingButton.Parent.Visible = .F.