Here is the second cut at the menu non-modal application:
|
This version is run, the Vermont Views error reporting system no longer pops up. A file can be viewed. Switching between the W_View window and the M_Main menu using the mouse is possible. The View menu field can be selected to specify a different file. However, when the View menu field is selected to do this, it causes two W_View windows to be on the screen. This is hard to notice because both windows are the same size and occupy the same position on the screen. But if you move or resize the top W_View window, you will notice another W_View window underneath. (Depending on how you think the application should work, this may be OK.)
When a file is being viewed in the W_View window, the window can be removed from the screen and the memory freed by pressing the Esc key. At first glance, everything is working OK. But what about the memory file that has been allocated and associated with this window? This memory file is not freed by the AUTOFREE flag—only the window structure is freed.
Therefore, there is an MFILE structure sitting in memory that can no longer be accessed. In fact, if two files had been viewed and Esc pressed for both, there would be two MFILE structures sitting in memory. If the user kept doing this, the application would eventually run out of memory. A way of freeing the associated memory file or using only a single memory file must be found.
There's another problem. If the user selects Quit from the main menu while the W_View window is on the screen, he or she is placed in the W_View window rather than exiting the program. (We've already seen this behavior in the first application example in the appendix.) The File sub-menu is also left on the screen and can be processed by itself. This is a major problem because the File sub-menu had a pointer to its parent—a parent that is no longer on the screen and may no longer be in memory if the AUTOFREE flag was specified for M_Main.