Jim Schram
Sun, 5 Mar 2000 21:00:43 -0800
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