The "latest document" that I was referring to is the reference document from the Garnet SDK.
Laurie "Dave Lippincott" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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/
