Paul,
One thing that will work is to split the code that calls the 'secondary' form. If the call to the form is the last line in the method code, then the program will go to the secondary form and put the primary form on hold. When you exit the secondary form you can call a Primary form method in the QueryUnload().

HTH
Barbara



>Thanks for the replies. Here is some background. I am working in a very large accounting application which was written in FoxPro 2.6. All windows were created in code (no .scx's). At this point, half of the application has been converted to VFP forms, but the menuing system is still using the old define window ... with @ get's for buttons. These of course occur in loops controlling the flow of operation. Selecting buttons calls prg's, some of which call newly created/converted vfp forms, and some of which create old style windows. We have not had any problems because in our code we have issued READ EVENTS after every form with a clear events in the destroy method for that form.
>
>We are now running into a problem because we have a few situations where we have issued a read events to start a form, and then need be able to call another module from within the form which pops up that modules menu window and eventually one of more forms defined in that module. At this point, when we create a new form we cannot issue READ EVENTS because it is allready active. This means that all of the code continues to execute, including setup/release of variables, opening/closing databases, and the menu loop.
>
>We can set a form to be modal, in which case the user cannot access the menu. Menu access is important because there are several features in the menu that customers need access to including lookup tables, browses, help, etc.
>
>Now, before anyone gets too excited, I do know that what we *should* be doing is encapsulating all code into forms, getting our menus into forms or the menu and out of loops, etc. We are moving in that direction, however due to the size of the app, and a lot of other variables, that is a very slow process. We could stop everything else and do that conversion, but doing so would only put us out of business the fast way.
>
>Currently, we are working with two solutions. The first is to use the menu workaround for modal forms. This seems to work, but my boss doesn't like the menu "flash" that results as you move through the software, so he wants to know what else is available.
>
>The other solution is to try to make VFP formsets work with the WindowType=2 property which is only supposed to be available in converted 2.6 forms, but works exactly like we need it too. I don't think this is a good idea for several reasons, nevertheless we are looking into it.
>
>So, to get back to my question...
>
>Is there any way besides read events or making a form modal to make code execution wait for a form to close before continuing?
>
>Any input is welcome.