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

Reply via email to