> 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?
> When do you think we could obtain the 3.3 or 3.5 source? :-)
I have no idea... I'd like it myself, actually, for use when I'm wearing my "3rd
Party Developer" hat...
> 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.
Plenty of problems to consider here...
Jesse
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
