Hi Mike,
Modeless forms are really not that difficult to program around. Nearly all windows applications are designed around modeless forms.
I have a main form that is modeless that has buttons for different functions that my program does. When the user clicks a button on the main form (or selects a menu option) it calls other forms in the application, about 90% of which are also modelsss.
1. The first thing is to have a main program that sets up the application environment, sets up ON SHUTDOWN procedures, calls the main form, issues READ EVENTS and has cleanup code then quit.
Example of what your main program should contain:
Initialize any application private variables.
ON SHUTDOWN do Myshutdownproc
Set default folder and path if required.
Check for registration info if required.
Set up menu if used
do main form
READ EVENTS
close all open forms
do any other cleanup code
close all
clear all
flush
on shutdown
quit
2. Create an on shutdown procedure that you specify in the ON SHUTDOWN Do ... that executes when the user quits the application or it is shutdown by Windows to allow graceful exit. Normally this proceudre contains code that releases any open forms by interating through _screen.forms collection and releasing each one. Then it issues CLEAR EVENTS. Many people place close all, clear all and quit in this procedure. I have found it better to release all forms in this procedure and issue CLEAR EVENTS, which returns control back to the main procedure just after READ EVENTS and perform the rest of the cleanup there, especially if there are modal forms involved.
3. The main form, if used as the main interface to the application, whould have code in its QueryUnload event that issues CLEAR EVENTS. You may also issue CLEAR EVENTS in the File menu option EXIT or Quit. The main form may also have a quit button that terminates the application by issuing CLEAR EVENTS. CLEAR EVENTS will return control to the next line after READ EVEBTS in the main procedure after any other pending event or method code is finished.
4. The other forms in the application should not issue CLEAR EVENTS unless you want the application to termninate from these sub forms. They should just RELEASE and return control to the main form and / or menu.
With an ON SHUTDOWN procedure, you can even eliminate all of the CLEAR EVENTS (except the one in the on shutdown proc) and just use QUIT when you want to exit the application.
In one of my applications there are 98 forms and all but 10 are modeless. Although it is really not pactical, you can open and minimize as many forms as you want, switching between. I have tested 30 forms open at once, switching between forms. I even have a timer that checks for user inactivity and system messages that may indicate that auto shutdown is required. When there is no activity for more that 20 minutes, or the another workstation requests exclusive use (all out), it issues QUIT which fires the ON SHUTDOWN procedure that does the graceful exit, releasing all forms, firing all cleanup code in each, and terminates the application. It also responds in the same way from the task bar close option. I know it really sounds complicated, but it really is not.
You may also benefit from the help file under Developing Applications Using the Application Framework. There are many VFP application frameworks that can manage this for you as well, but you really need to understand the basic sequence of events. You might check out the coverage profiler and Event Tracking functions in VFP to learn more about the sequence of events when using modeless forms when you do certain actions. It may help you understand where to put your code to do what you want to do.
In my experience, I have found modal forms to cause me more problems that modeless ones.
HTH
Elmer
