Unless I'm reading your problem incorrectly, you may have misinterpreted the functionality of EvtSetNullEventTick. The number you pass to EvtSetNullEventTick is the max number of ticks the OS will allow to pass before it will post a nilEvent. If you pass TimGetTicks(), the OS will *wait* TimGetTicks not post at TimGetTicks. If you need to post a nilEvent immediately, either use EvtSetNullEventTick(0) or post the event yourself. i.e. if TimGetTicks returns 1234, you could end up waiting 20 minutes for the nilEvent. Try passing a smaller number or have the OS post nilEvents more frequently and just check the number of ticks or the actual time to see if you are done (or should do something). There have been a number of post with example code on how to effectively use nilEvents to create a timing loop.
----- Original Message ----- From: "Laurie Davis" <[EMAIL PROTECTED]> Newsgroups: palm-dev-forum To: "Palm Developer Forum" <[EMAIL PROTECTED]> Sent: Monday, March 22, 2004 10:44 AM Subject: Unreliable nilEvents on Cobalt > I use nilEvents to do some background processing in my application. > This has worked ok so far, but is not reliable on Cobalt. After > processing the nilEvent, I immediately generate another nilEvent using: > > EvtSetNullEventTick(TimGetTicks()); > > I do this repetitively until the processing is complete. > > On Cobalt, I regularly miss nilEvents. I can reduce the problem > by adding a delay: > > EvtSetNullEventTick(TimGetTicks() + delayTicks); > > By increasing delayTicks I can reduce the likelyhood of missing > nilEvents, but this obviously slows down the background processing. > > Is this a bug in Cobalt? > > Laurie > > > > -- > For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
