At 10:59 PM -0500 2000/03/04, D. DeVecchio wrote:
> > IMPORTANT: Because the procP pointer is used to directly
> > call the procedure, the pointer must remain valid from the time
> > AlmSetProcAlarm is called to the time the alarm is triggered.
>
>Will a pointer to a function in my program be valid after I respond to a
>"AppStopEvent"?
Only if you've taken extra measures to ensure it's validity. BTW, it may appear to
work correctly most of the time, but you are at risk of crashing the device if, for
example, the storage heap is compacted after you respond to the appStopEvent and your
application's code segment which contained the proc alarm handler is moved.
>If the answer to the above question is no, then it would seem that
>procedure alarms can only be called within the confines of a currently
>active application (or within a library opened by that application). Am
>I correct in this belief? or am I missing something?
That's correct; the code pointed to by the proc pointer passed into AlmSetProcAlarm
must exist when the alarm triggers, or the device will crash. Your app should
therefore be sure to remove any proc alarms you have set before your app quits, unless
of course you've taken specific measures to ensure that the proc pointer does remain
valid. There are several ways to accomplish this, but the obvious question is why not
use a launch code based alarm if it's expected to go off after your application has
quit? Both types of alarms originate from the main event loop of the currently
executing application, so there's little difference between the two types other than
offering an alternative notification mechanism. Proc alarms were primarily intended
for use by non-applications (e.g. shared libraries, hacks, extensions, etc. -- things
that do not receive launch codes).
Regards,
Jim Schram
Palm Incorporated
Partner Engineering
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
