On Mon, Dec 03, 2001 at 09:52:34AM -0500, Avilla, Dane wrote:
> I agree about trapping specific keyDownEvents, but unfortunately that
> doesn't work well in cases where the user pops up the soft keyboard on a
> form, and then hits a hard key. Since the keyboard has its own event loop,
> it will allow the app to exit, when I don't want it to.
Yes. Many bets are off when things with their own event loops have
popped up. This caused David Kendall's problem, and lots of other
problems people encounter regularly too.
IMHO your only good answer is "don't do that". Don't let the keyboard
dialog or anything else with its own even loop come up when you need
to prevent your app from quitting. But I suspect your users won't
like that...
It seems to me that a good way (with good Zen) to handle your real
problem is to allow the user to quit at any time, but to consider a
half-edited record not to be committed. Do your record validation
when the user presses Okay on the edit form, and don't commit the record
to the Palm OS database until then -- if they quit your app while in the
edit form, save the half-edited record in a separate database or in your
app prefs or somewhere. (Or only do this if the record really is invalid.)
If they do a sync when there's such a half-edited record, it won't be
synced: you probably want to put a note in the log, but your fragile
backend database will be safe from the evil half-edited record.
> I'm a little confused as to your doc reference: I looked at p. 71 as you
> suggested, and didn't see anything that specifically forbids ignorning
> appStopEvent. On p. 71 I saw the following: [...] "In response, an
> application has to exit its event loop, close any open files and forms,
> and exit."
I read this sentence as "An application MUST respond thus; otherwise
the system's behaviour is undefined", but perhaps I spend too much time
reading standards documents.
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
