Hi, again. Bob and Ben, thank you, again, for your previous answers to the thread I started on Dec. 6. This post is further to that thread. (Ben, I have a couple of more questions for you at the end.)
I did some experimenting last evening and found that there ARE some events that DO occur when a Palm is "turned off" and (sometimes) "turned on". There are some special "virtual" characters that are sent in keyDownEvents, including: vchrHardPower (the hard "power"key) vchrHard1 to |- the four application "hard" keys vchrHard4 / vchrPowerOff - sent just after the autoOffChr or after a vchrHardPower which turns the Palm off." autoOffChr - sent when the auto-off timer expires. In addition to the .chr element containing the character code, the keyDownEvent data structure also includes a ".modifiers" word that contains bit-flags associatied with the event. In the case of the four application hard keys (vchrHard1 to vchrHard4), if the hard key turns on the Palm after a power-off, the poweredOnKeyMask modifier bit is set in the keyDownEvent data structure after the Palm is re-awakened. So, here is what I found out with my experimentation (all experiments were run on both the POSE and an m500, both running PalmOS 4.0). While the test application was running, a user power-key press (to turn off the palm) would send vchrHardPower (with poweredOnKeyMask OFF), followed by a vchrPowerOff in two separate keyDownEvents. If the auto-off timer expires, the OS will send the autoOffChr followed by the vchrPowerOff. So, these events can be used by the application to flag the fact that the palm is on its way "down". However, comments in Chars.h say that the vchrPowerOff character was only defined (and sent) in OS's after 3.2. So, in pre-3.2 OS's (I presume) the vchrHardPower and autoOffChr codes can be used. Also, in the case of the auto-off timer, the application cannot "block" the turning off the palm. (I tried using an alert dialogue when my aplication received the vchrPowerOff character. It DID block for the user power-key press, but NOT for the auto-off timer.) If one of the four application "hard" keys is pressed while the palm is off, the appropriate vchrHardN character is sent with the poweredOnKeyMask bit ON. This can be used by the application to signal that the palm has just been re-awakened. However, unfortunately and for some strange reason known only to the PalmOS authors, it appears that no keyDownEvent is enqueued when the palm is turned back on with the power key. ( BUMMER! :-( ) (At least, my application did not receive one, and I intercepted the keyDownEvents before passing them on to the SysEventHandler.) So, anyway, it seems that I CAN flag the fact that the two timer counters are ABOUT to get unsynchronized (from the power-off keyDownEvents), then use any later event to trigger a re-synchronization procedure. Any timestamp event that occurs while the counters are unsynchronized, can be flagged as "preliminary" or "approximate", and be updated after a successful re-sync. of the two timers. BEN: Is a running application guaranteed to receive the vchrHardPower or autoOffChr keyDownEvent before the palm goes to sleep? Is there anything else taht will put the palm to sleep while an application is running? Thanks and regards, Ed. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
