From: "Blake Winton" <[EMAIL PROTECTED]> > > From: "John Crouch" <[EMAIL PROTECTED]> > > > 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? > More importantly, why document them at all if an undocumented set of common operating system functions will throw them away. It's similar to having a function call mechanism that will randomly fail to action the function call. I really can't see how it's usable. I understand the practical problems with implementing it, but if custom events have these problems the documentation should say so IN BIG LETTERS.
> 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? > Yes. Did that, works well, never had a problem with it. Just used a 'xxxGetEvent' call in the app event loop. This has some secondary advantages also. One is that you can create a queue which is deeper than the standard event queue so that you can stack events up ten or twenty deep before you get to processing them. Chris Tutty -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
