If you call an OS API that presents a modal dialog and blocks until that dialog is closed, you're effectively asking the OS to run it's own event loop for that dialog. It can't very well run your event loop if it's not going to return until the dialog closes.
If you use FrmDoDialog to present the dialog, you even have the option of setting up your own event handler that gets first crack at every event precessed by the dialog's event loop. You also have the option of writing the entire event loop for the dialog from scratch. Or, you can use a non-blocking approach with FrmPopupForm, so that your main event loop continues to run while the dialog is open. I do agree that it would be nice if you could set up your own event handler that gets first crack at every event processed by FrmCustomAlert. Because the event queue refers to forms and form objects by ID, these events can't stick around when you switch applications. So, the OS flushes the main event queue when switching apps. Only the key queue survives the switch. The key queue is also thread safe, whereas the main event queue is not. My advice is to avoid using custom events for communicating information within your application. I think custom events may have some utility, but I do agree that they may do more harm than good because they sure seem more useful than they really are. So, what do you do instead? Well, there are probably lots of good alternatives. One approach to consider: Set globals that indicate that the app needs to do something. In your main event loop, before processing an event, check the globals, and in a suitable priority order, take the necessary actions. For low priority actions that should occur after processing all other events, check the globals in your nilEvent handler. -- Peter Epstein -----Original Message----- From: Blake Winton [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 8:48 AM To: Palm Developer Forum Cc: [EMAIL PROTECTED] Subject: RE: Events during Alert Box > From: "John Crouch" <[EMAIL PROTECTED]> > > When an alert box is being displayed via the > > FrmCustomAlert() function call, my app does not > > receive any events. We have a need to trap events > > during this time. Am I missing something or is > > this correct - we don't get events when an alert > > box is up? > No. There are a surprisingly large number of > standard PalmOS functions that will shut your app > out. This is ridiculous. I put up with, and even defend a large number of Palm's fairly obviously wrong decisions, (multiple-select lists, for example,) but this is the straw that broke the camel's back. Why even add user events, if we are going to lose them at random intervals? > The alternative I employed was to write replacement > functions for the Palm alert functions and to pray > that people wouldn't bring up the keyboard and leave > it there. If your only problem is with alert boxes > then the replacement code isn't too hard to write. This was what we started doing, with our "EventSafeFrmCustomAlert" method, but after we found out that the keyboard dialog would eat all our events as well, we decided that we just can't go down that road. > As Peter's reply indicated, the other answer to this > is to implement low-level mechanisms at OS level to > trap events below the interface. Doing this in a > robust manner on a variety of PalmOS versions is a > task I'm really not looking forward to. As a third alternative, we're looking into creating our own event queue which slurps up all the standard events whenever it gets called, and we would ask for events from it. That way any random Palm function could suck all the events off of the Palm event queue, and not cause the rest of our programs to fail. Has anyone done that before, and are there any obvious pitfalls I should avoid? The rest of the rant deleted here... Thanks, Blake. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
