>>I now realize that (of course) you are correct.... and I can hit
>>the database and
>extract the information I need..... but I'm worried about spending
>too much time
>performing these actions in response to a sysAppLaunchCmdAlarmTriggered
>launch code. According to the documentation, one should not perform any
>significant (time-consuming) tasks at this point since the OS has to
>inform all
>installed apps. In order to determine the next alarm time I need to
>read and compare
>records from several DBs and do some processing.
Most apps will probably not respond to sysAppLaunchCmdAlarmTriggered,
or return false, so only a few will get sysAppLaunchCmdDisplayAlarm.
So, I think you can do a fair amount of stuff done in the
sysAppLaunchCmdDisplayAlarm launch handing. (I have one app that does
quite a lot. It gets tricky when I open, use, and close a NetLib
connection in the alarm handling, but other than that, it seems to
work fine.) Of course, the docs are still right--you should do as
little as possible. Hitting a single database for some processing
shouldn't be a problem.
One possible approach would be to partition the work up into small
chunks and schedule a series of alarms, say, 10 seconds apart. Do one
chunk in each alarm. That's kind of a kludgy way to emulate a
multitasking OS in a non-multitasking environment, but, hey--you do
what you gotta do to solve the problem given the constraints of the
platform.
Regards,
Steve Mann
--
-------------------------------------------
Creative Digital Publishing Inc.
1315 Palm Street, San Luis Obispo, CA 93401-3117
-------------------------------------------
805.784.9461 805.784.9462 (fax)
[EMAIL PROTECTED] http://www.cdpubs.com
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
