Danny,
Thanks for the great references.
It seems the easiest and (unfortunately) sneakiest approach would be to call
the (undocumented) sysTrapHwrDisplaySleep which before OS 3.5 was
sysTrapHwrLCDSleep. This way I wouldn't have to change the overall way my
application runs.
I'm using alarms to automatically start and stop my app, so the more
supported route is using procedure alarms (even though its in a way they
were probably not originally intended to be used.) From reading the
articles you referenced it occurred to me that to get around the potentially
tricky issues of locking and protecting my databases and resources I could
instead briefly wake up with a non-procedure alarm, SysUIAppSwitch() to my
app, register a procedure alarm with a pointer to one of my app's functions
to trigger immediately, and then power the device off programmatically.
When the procedure alarm triggers I could then be assured that my function
pointer is still valid (since my app's code resource is currently loaded)
and my globals are available. Is that right?
When I'm done running in my ProcAlarm routine, I set another non-procedure
alarm to wake up my app again so that it can continue where it left off and
shut down (which may entail restoring whatever app was running before mine
came up). This way I avoid loading and unloading entire applications during
the procedure alarm (though I'm not sure if I should worry about this or
not.)
This approach requires that the device fully power up briefly once when the
app starts up, and once again when it shuts down. I know alarms deliver 2
launch codes: Does the device power up fully before either is delivered, or
only for the latter? If so, would it be dangerous to do my start-up and
shut-down when the first alarm launch code triggers? The documentation says
you should do very little when the first alarm launch code is triggered. I
would normally wait for the second launch code, make sure my app is loaded
(or launch it if it is not) and then do my work. Should I assume a
SysUIAppSwitch() is too much to perform on the first alarm launch code?
Thanks again for your help,
Scott Schoen
Danny Epstein [EMAIL PROTECTED] wrote in message
news:82466@palm-dev-forum...
Does anybody know if there's a way to run an application with the LCD
(display) turned off to conserve power?
A search of the archives for procedure alarm turned up this post by Jim
Schram:
http://www.escribe.com/computing/pcpqa/m12458.html
I would add another option to Jim's list: lock (one of) your app's code
resource(s) and protect your app's database. This will prevent your
callback
from being moved. It will also prevent your app from being deleted, but
that's pretty much a given with any procedure alarm.
I've heard that the LCD drains a lot of power ...
See Peter's post on this subject:
http://www.escribe.com/computing/pcpqa/m44248.html
I would assume I have no globals available
Correct: your callback won't necessarily have access to globals. Your app
may or may not be the current UI app at the time the callback is invoked.
Any restrictions on running an event loop within a ProcAlarm?
For non-procedure alarms (ie. using a launch code), there are two
launches,
one for trigger and one for display. The former isn't allowed to do UI
(ie.
run an event loop). The latter is. A procedure alarms only gets the
equivalent of a trigger invocation. You're not allowed to do UI in a
procedure alarm. You can use another (non-procedure) alarm if you needed
to
do UI. Or you could use the Attention Manager on Palm OS 4.0 and later.
To summarize, what you're trying to do isn't easy, but is possible. :)
--
Danny @ PalmSource
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
