I OS 5 SDK docs still indicate min ticks until next nilEvent. Either docs weren't changed or it was changed for Cobalt. I haven't read the Cobalt docs yet. Ben, any clarification or reason why the Knowledgebase doesn't indicate why EvtSetNullEventTick is documented wrong? Past post I can dig up from helpful PalmSource employees indicate that EvtSetNullEventTick sets the period for nilEvents not an absolute time to generate one by. Then again, I've been wrong before.
----- Original Message ----- From: "Laurie Davis" <[EMAIL PROTECTED]> Newsgroups: palm-dev-forum To: "Palm Developer Forum" <[EMAIL PROTECTED]> Sent: Monday, March 22, 2004 12:21 PM Subject: Re: Unreliable nilEvents on Cobalt > There has been a lot of discussion regarding EvtSetNullEventTick, and I > thought that the conclusion was that the earlier documentation was wrong. > The latest document says that the parameter is "The time, in ticks, since > the > last reset by which a nilEvent is to be added to the queue." This is the > way that it seems to be working - by setting the parameter to TimGetTicks, > I get another nilEvent immediately. The only problem is that with Cobalt > sometimes a nilEvent does not get generated. > > Laurie > > > "Dave Lippincott" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > 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/ > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
