Craig Evans <[EMAIL PROTECTED]> wrote:
> nCheckAlarmTime = AlmGetAlarm(...) ; // Get the next alarm from the required
> db
>
> // If no alarm set, or required alarm time < the next alarm already set
> if (nCheckAlarmTime == 0 || nCheckAlarmTime > nSetAlarmTime)
> {
> // do your add to the datebook db, and then set alarm
> AlmSetAlarm(...) ;
> }
Your idea of elegance seems upside down to me.
Why do you expect that changing the Datebook's alarm behind its back will
not confuse it? You've violated encapsulation. How do you know that the
Datebook doesn't maintain some internal state keyed by something about the
alarm that you can't reproduce?
Looking at the Datebook code in the 3.5 SDK, I don't think it's obvious
that you wouldn't have to do something clever with the ref parameter to
the alarm functions. Even if you do convince yourself from the source
code, there's no reason to believe that other versions of the Datebook
would work the same way.
To be sure, just adding records to the datebook is violating encapsulation.
But we know that people want to do that, so the record format and DateDB.c
are more or less kind of supported and we make a more or less half-hearted
attempt not to change them too gratuitously [1]. But playing with its
alarm is another matter.
If you read the documentation of sysAppLaunchCmdSyncNotify (and look at
SyncNotification() in the Datebook code), you'll see that what you need is
exactly what this launch code is for!
> I think this style of solution that is self contained in your code might be
> more elegant than trying to trigger Datebook with a suspect launch code.
Given that there are documented launch codes to do what you want, it seems
to me that it's much more elegant to use them. I'm curious to know why
you think a documented standard launch code is "suspect".
John
[1] Not an official statement of Palm, Inc. Take with appropriate pinches
of salt. :-)
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
