[EMAIL PROTECTED] wrote:
> > Here's the stack trace of a TimSetSeconds that complained:
> > 0000C50C #0000003022 10C844BE TimSetSeconds+00A4
> > 0000C4E0 #0000000044 10C84920 PrvBroadcastTimeChange+0028
> > 0000C4C2 #0000000030 10C454DE SysNotifyBroadcast+0114
> ...
> > Fortunately, it appears that you have preserved the order of things for
> TimSetSeconds.
>
> Okay, you're really lucky. We tried to change it, but it was only changed in
> the simulator version of the TimeMgr, and not the version used when running on
> actual hardware (or Poser). It would probably be a really good idea NOT to
> depend on this, since we might "fix" it for the next release... or, rather, why
> do you think we _shouldn't_ change it?
For backward compatibility. Introduce a TimSetSecondsDeferred or something for the
future.
Incidentally, I would rather not rely on luck in the future. I'm one of those who are
trying to make a full time living out of the
Palm Computing Platform and thus promote it. I would like to continue being supported
by Palm and not tinkered with. :-)
> > For the record, my recommendation is that ALL notifications should be
> > sent with a separate stack from the UI app stack.
>
> Good idea, but what do you do if the allocation fails?
> Or are you suggesting that we permenantly allocate XX bytes in the dynamic heap
> for use as a stack during broadcasts? If so, what do you do when a broadcast
> handler starts another broadcast? Then some of your broadcast-stack is already
> used up, and the sub-handlers will have less of it for their own use.
I was suggesting a one off allocation for efficiency (this efficiency assumption needs
to be profiled to really know). For nested
notifications I would suggest dynamically allocating a stack. I imagine nested
notifications would occur much less often. If you
can't allocate the stack then the notification fails and SysNotifyBroadcast or
SysNotifyBroadcastDeferred return an error. All
callers of these SysNotify calls should presently catch exceptions so I don't see a
problem.
> Plenty of problems to consider here...
Not as many as we have had. :-)
Kind regards,
Christopher
--
Christopher Hunt
Class Action Pty. Ltd.
Complete time zone management for the Palm(tm) connected organizer.
Check out http://www.classactionpl.com/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
