I see two work-arounds. (1) Don't put up the original FrmCustomAlert -- use a regular (modal) form, launch it with FrmDoDialog, have your own form event handler, and trap (return handled == true on them) those annoying hardkey events. You could create your own MyCustomAlert to handle this if it must be done in more than one place.
(2) Don't put up the final FrmCustomAlert off of the appStop event (you shouldn't be popping up new GUI there, isn't prudent). Swallow the app stop event, set an internal semaphore, push some other (say a NIL) event onto the event queue, and pop the FrmCustomAlert off of the other (NIL) event when the semaphore is set. If the user really wants to exit (or is allowed to by you, oh omniscient programmer), you can change your semaphore's state so that the appStop event really works this time. This would allow the form close of the original FormCustomAlert to fully process. Baroque, tricky, but should work. I would recommend (1), as (2) is seems somewhat involute to me. Of course, you could also just change the final FrmCustomAlert as in (1) as well... -bob (there be many way to skin the cat, grasshopper) mckenzie -----Original Message----- From: Peter Laakmann [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 21, 2001 8:30 PM To: Palm Developer Forum Subject: Problem calling FrmCustomAlert, returning via appStopEvent, then calling FrmCustomAlert again when handling appStopEvent Hello all, I experience a problem with the following: 1) When I call FrmCustomAlert() 2) It returns with the default value/key because the user hit an application key. The code following the FrmCustomAlert(), not knowing how it got its response [btw, is there _any_ way to tell how?], proceeds to call FrmGotoForm() [to go to another form, besides the one active during the FrmCustomAlert()] 3) In my event loop, when I hit upon that appStopEvent, I generate _another_ FrmCustomAlert() [this is conditional, of course, but this case is where the problem arises]. Anyways, to make a long story short, the original/active Form (step 1) never receives a FrmCloseEvent, despite the fact that the application does goto the form called with the FrmGotoForm() function. [This, of course, causes all sorts of problems.] Furthermore, the second FrmCustomAlert() appears instantaneously, barely perceptible except during debug] and closes without any user interaction. It would appear to me that for some reason, something is getting crossed here, such that the second Alert Dialog is receiving and handling the FrmCloseEvent for my original Form. I've isolated this problem in a number of my forms where I perform the above steps and it simply never happens when that last FrmCustomAlert() call is not made. In other words, it's very much repeatable. Does anyone have any idea what I might be doing wrong? Could this be a bug/feature? If not, are there any decent work-arounds? I _need_ to ignore the appStopEvent in all but a few forms, but I'd also like to notify the user as to the reason. Going without FrmCustomAlert would be troublesome and even then I'm not sure it'd solve this particular problem. Is there a creative way to isolate the appStopEvent just for those times when an alert dialog is present?... Any help will be greatly appreciated. Thanks -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
