Harry wrote:
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
Good idea, but one more thing: you should use a ProcAlarm, because the
other alarm will eventual switch on the display.
Regards
Henk
BTW: Aren't there any processor counters to read?
--
-------------------------------------------------------------------------
Henk Jonas [EMAIL PROTECTED]
Palm OS ® certified developer
Please contact me, if you need an off-side contract worker.
-------------------------------------------------------------------------
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
