Jim Schram,
Thanks again for your continuing help in this matter. I am sorry if
this is the second reply you have received to this particular post. I
am not seeing the post I thought I made on the list, nor can I find the
outgoing copy in my outbox.
On Wed, 8 Mar 2000 00:03:39 -0800, you said:
>
> The recomended way is to use a launch code and finish the trigger routine
> by turning off the diplay... by EvtEnqueueKey(vchrPowerOff, 0, commandKeyMask);
If I convert my procedure alarm to a launch code alarm, and then shut
off the screen when I am done, what happens if I happen to be working in
date book when the would-be proc alarm triggers in the background? Will
it not suddenly "turn off" on me? If so, is there some way to tell if
the device was powered up just for the (launch code) alarm or if it has
been on for a while (presumably because the device was in use by another
user when the alarm called)? In this manner I could avoid turning off
the display if it was in use by the owner.
>
> my next recommendation is to use a shared library, extension, or hack
> to contain the alarm callback function.... each inherently protects
> the code which registers the alarm.
Are libraries _always_ stored in non-movable RAM? Or do they only
become "locked" after the "SysLibLoad" call and before the SysLibRemove
call.
I have not heard of extensions in this context. I thought extension was
sort of synonymous with Hack. Are there resources where I can go to
find out more about what is required to build Hacks and Extensions?
>
> Lastly, if neither of the above options are acceptable, is to allocate
> a chunk, set it's owner to 0 so that it doesn't auto-deallocate when
> your application quits, copy your function's opcodes there, and pass
> the chunk pointer to AlmSetProcAlarm.
For the disadvantages you mention, this is obviously not very desirable.
One way to make it more palatable would be for the main program to store
the handle the proc code in a feature and then to remove it when the
ProcAlarm had sounded. In this manner, the code segment (less than
1kB) would only be in memory as an unmoveable chunk for as long as it
absolutely needed to be. Once the process alarm triggered, it could be
removed.
derik
email: [EMAIL PROTECTED]
WWW: http://www.pobox.com/~derik
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
