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/
