> 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/
