My application also works with alarms that user establishes, to
remember him activities to do, appointments..........
I'm using timers, they are "quite" precise and I'm afraid it's the only
way to achieve what you want.

On the other hand, my application synchronizes with a server using
Merge Repplication and my problem is that time of the PDA must be
always the same as server's, and it's not.
If you switch on/off the PDA, soft-reset and so on, time of the PDA
varies from time of the server and they are not always the same.
Therefore, an alarm that had been established from server side to fire
at 8:00 exactly, in a couple or days or week of PDA using, could fire
in the PDA at 8:01 or 8:02.
If tasks to do are not critical........timers are quite a good choice.

Regards.

It's not going to be guaranteed to be that close (or even nearly that
close).  If you look at the clock now, decide how long until the alarm is
supposed to fire, then do a WaitForSingleObject() on some event (typically
an event indicating that the main part of your code wants you to exit), with
a time-out set to the time before the alarm should fire, you should get
something pretty accurate.  That is:

// Get current time

// Subtract from alarm target time to figure out how many ms (yes,
milliseconds), until the alarm
// should fire.

// Wait for either a) the exit event to be set or b) for the time-out to
occur.
result = WaitForSingleObject( exitEvent, msTillAlarm );
if ( result == WAIT_TIMEOUT )
{
   // The time-out occurred, so do whatever you do to sound the alarm.
}
else
{
   // The main application set the exit event.  Presumably, we should
terminate this thread.
}

If you ever set alarms on your Pocket PC, you see that they seldom fire
exactly when requested, but they're close enough for most things (if you set
your alarm clock for 6am, you don't really care if it goes off at 6:00:00 or
6:00:59; at worst, you're 60 seconds late for work).  They use
CeRunAppAtTime().

Paul T.