>>>If the form is modal, yep, this is the way. If not, well then the other way is to have the form tied to a variable, by either instantiating form from a class or Do Form ... Name oFrm, and then overriding all the code which would lead to release of the form (.queryunload(), cancelbutton.click... best checking for this.visible in .release()), and just hiding it instead. The variable referencing it (oFrm in my example) can be then examined for return values or any other properties, and the form can be released programmatically.
>>
>>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.
>>
>>But, this certainly is one way to do it.
>
>I've seen it done both ways. Generally, the forms which set or return a value are modal, but that's just a habit enforced by Windows, based on the idea that if the users were able to leave the window, before doing what it wants or at least canceling, there would be too many windows open. Which may have been a concern with the memory constraints of Windows 3.x or w9x, but at this moment I have twelve windows open and I'm quite fine with that. Some of these windows are open for days - so what. And under Linux, dialogs are not necessarily modal, and it works fine. You may get a message that the value is not set, or may get the old value used because you didn't set it yet - but opening a dialog is not a showstopper.
>
>Of course, VFP is so very Windowsy, despite having developed its window system for a Mac. So it has its own set of behaviors designed for Windowses, but hey, it's Fox, we can subclass our own fingers if we want :).

I personally think that modal form is a better way to make sure that user answers an important question rather than leave the question unanswered for a long time (even days), while the user is distracted by something else in the program and pursues a totally different path. But that could also be just my own habit more than a good user interface rule, I don't know. I do find that at least people who use my programs want to be led by the hand to some degree, and they do get confused pretty easily, so modal prompts work really, really well for these people.

Maybe I should ask Guy Kawasaki about this...