Hi Jan, Can I ask why you are passing SysTicksPerSecond() as an argument for EvtGetEvent? This is telling it to wait up to 1 second for an event to return. If you want zero delay, you can pass zero for this argument in which case the function will return immediately with either the next event in the queue or nilEvent if there are none.
Also, the speed of the emulator isn't the same as the speed of an actual device. I believe the emulator runs as fast as it can, which means that you might not notice the delay, but it could still be there. This is from the help file: "Note that a timeout value greater than or equal to zero is simply the maximum number of ticks which can elapse before EvtGetEvent returns an event. If any other event--including a nilEvent--occurs before this time has elapsed, EvtGetEvent will return that event. Otherwise, once the specified time has elapsed EvtGetEvent generates and returns a nilEvent. If you supply a value of zero for the timeout parameter, EvtGetEvent returns the event currently in the queue, or, if there aren't any events in the queue, it immediately generates and returns a nilEvent." -- Tim Kostka http://www.nuprograms.com "Jan Slodicka" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hello, > > very strange thing: > > if( EvtEventAvail() ) > { > EventType event ; > EvtGetEvent( &event, SysTicksPerSecond() ); > // Returns nil event after 1 second delay > } > > This delay happens only at special occasions, yet it happens. Can somebody > explain that? > > It's clear that negative impact can be relieved if using delay 1. But that > is no answer. The question is why EvtEventAvail() reports something what is > not true. > > > Here is the more complete code excerpt: > do { > EvtGetEvent(&event, SysTicksPerSecond()); > > if( event.eType == frmOpenEvent ) > bFormOpened = true ; > > if( !SysHandleEvent(&event) ) > FrmDispatchEvent(&event) ; > > if( bFormOpened && !EvtEventAvail() ) > { > // some lengthy processing > } > } while (event.eType != appStopEvent); > > The critical event sequence: > winExitEvent > winEnterEvent > frmOpenEvent > penUpEvent > nilEvent > > On the Tungsten/t the last nilEvent comes with 1 sec delay in most cases, > occasionally there is no delay. On the emulator there is never any delay. > > Looks like the problem relates to the penUpEvent, that seems to play a > special role in the event processing. > > > Regards, > Jan Slodicka > > > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
