At 4:14 PM +0100 2001/12/04, John Marshall wrote: >Then the application's main event loop gets a fldChanged event *for a >field which no longer exists* and explodes.
Just to offer a comment... John's analysis of this behavior is 100% accurate. I've debugged a number of problems of this sort, where coming back from a nested event loop the event queue contains events for the now-closed form [independent of the position of the re-queued appStopEvent in the queue]. Unfortunately, there's no single easy solution as the events do not carry the form ID in every event record. It does usually carry a control ID which can be used to validate the event against the current form's list of controls and fields, but, even that is problematic for obvious reasons. One solution I've seen (which is more easily implemented via a C++ style UI framework) is to maintain a separate data structure containing a list of all forms' elements for event comparison, tied into a local event dispatch method such that these "rogue" events are invisibly eaten/ignored by the framework before being passed on to the form's local event handler. Obviously this adds a significant layer of complexity to the application, but it does solve the problem (and by virtue of the framework, unifies event management for all forms and controls in the app). So the "solution" is to ignore the extra event(s) -- the problem is how to detect their invalidity. Regards, Jim Schram Palm Incorporated Partner Engineering -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
