Does the emulator generate "extra" nil events that a real device doesn't?
I had something working fine on the emulator, but on the device it
behaved differently...
My app does some "background" processing. The backgrounding routine is
only called on nil events, and it returns a sleep time for the next
EvtGetEvent: if there's more work to be done, it sets the sleep time to a
few ticks (thus ensuring a nil event in the near future), otherwise it
returns evtWaitForever. So the top of my event loop looks something like
this:
do
{
EvtGetEvent(&event, timeoutTicks );
// Do a little background work on nil events, if we have globals
if( (event.eType == nilEvent) && (cmd ==
sysAppLaunchCmdNormalLaunch) )
timeoutTicks = gBackgrounder->WorkALittle();
...
User events can of course change the state of things so that the
backgrounder needs to start up again.
This design has an obvious flaw: once the backgrounder is finished the
first time and timeoutTicks becomes evtWaitForever, no nil events come
through again, so it never gets started up again: I need one nil event to
trigger the generation of more. But it took a while to find this, because
on the emulator I DO get stray nil events after, for instance, a penDown
or some other "normal" event. I've since changed it to get the
appropriate sleep time from another backgrounder routine before
EvtGetEvent is called, and that seems to be working fine.
But I'd still like to know if there is a difference in the way the
emulator generates nil events vs. a real device. And I suspect Keith and
the other emulator folk want to know, too (if they don't already).
(BTW, the device I'm using is a IIIx, OS 3.3, if that matters, and I'm
developing with CW6 Mac, emulator 3.0a6, compiling against SDK 3.5)
Dave Johnson
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
