Well, the type of forms having a result should be modal, like the messagebox itself is. In fact that's one of the main reasons it is modal, also because it requires your intention and intentionally locks out all other current forms.
Anyway, nonmodal forms are what makes an application more dynamically usable, so your intention is fine.
I don't second using READ EVENTS for that purpose, instead say bye bye to a linear main code running and rethink the whole concept of windows forms. Who needs an answer? Most often its a calling form, so you should pass that in, pass in THISFORM from the form starting the nonmodal form., You may even not need to pass in a variable then, because the newly started nonmodal form may use a form property of the calling form as controlsource and so the calling form can even know every in between stat of its own property, as it is bound to another forms control.
The complicated part of this is now you depend on the caller form not to release before the new form ends. But aside of that problem, in OOP it's much better to work with objects, which combine data and behaviour, so you could also start up another class instance and pass that forth and back. What comes in play here could be a overall supervisor, a form handler. The only thing to pay attention about is the scoping of such objects, the forms etc. One other key word to know is callback. This is rather what you do multiple times in an asynchronous running secondary thread, but can also apply the concept to called forms. When calling you also pass in the info which other object expects a callback into some mehtod or the setting of a certain property, which could also trigger some behaviour via having an assign method.
If you want your application to have multiple forms up and running, interacting with each other and staying responsive for users to use them in a non linear fashion, but in parallel, then you shouldn't think about suspending and waiting for a result, you should think of going on with something else or ending code to go into the already running READ EVENTS event waiting "loop". The called form has to become an active part of this and either know or as I already suggested get said what to do in the end.
You have many possibilities and don't need to do it as suggested, there are many ideas out there and obvious, if you break through your linear thinking. One thing is for sure though, you can't let retun code follow right away and put yourself into a sleep mode like read events does to pick up there when the nonmodal form ends. This is like wanting to have the cake and eat it, too. No, you have to stop, let READ EVENTS take over and program the called form in some way to call back.
If you have the difficulty, you don't control the code of the called form, it's a third party thing, then you have to make use of bindevents to react to this forms destroy event, for example, but please simply forget about the idea you can wait with something until the form ends and let code execution continue right after the DO FORM. What makes things easier is also staying off of DO FORM and rather go for OOP the full monty and have form classes you instanciate. That gives you a very powerful way to act on the form before you set it visible or call its Show method. Instead of passing in info you can set form properties, the form becomes your puppet, as you have a form object reference.
Bye, Olaf.
Notice: You already make heavy use of the nonlinear way of code execution, if you ever programmed more than one button on a form and thereby have alternative code executing depending on which button a user clicks. If a form is nonmodal that already means you know the procedure of starting a form, which after load does nothing more, so the callstack goes up to the READ EVENTS and then nothing happens and what happens next depends on which button is clicked. You already make use of OOP all the way in that respect.
