This one's a lovely challenge! Here is a conceptual solution (no code).
1. Have your app schedule an alarm every 30 secs. (use AlmSetAlarm or AlmSetProcAlarm). Whenever your app. gets control via this alarm, it does two things: 1.1. compare TimGetSeconds() with a time stamp stored previously in step 1.2 (see below). If this delta is > say 35 secs., you know the clock has been tampered with and reset is to the last time stamp + 15 secs. 1.2. if the check in 1.1. was ok, store the current system time at some reset-persistent place, e.g. a database record, an application preference. The nice thing is, even is the device is off (sleep mode), your app. will get the alarm and it can process it within a few cycles and without switching on the display - so the user won't notice this routine check. The impact on the power consumption of the device should be tolerable. If a user resets the device and changes the clock you just undo this change in a simple and effective way. The final question is, how long was the device in "reset mode" before your app regained control, i.e. how big is the delta between your stored timestamp and the actual time? Hint: the reset will set the SystemTicks back to 0; now if we take the currently elapsed ticks TimGetTicks()/TimTicksPerSecond() we have a good proxy for the actual time difference. What do you think? Harry -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
