At 2:15 PM -0700 5/26/99, Dan Rowley wrote:
> I think the "company line" is that nilEvents can come at any time and
>without warning - they are generated by the OS for various internal purposes
>and the timing/frequency is not guaranteed.
There is a guarantee! If you pass a timeout to EvtGetEvent, you are
guarateed to get some event on or before the timeout passes. If no other
events are generated, a nilEvent will be created for you when the timer
expires.
I think the problem is misreading the guarantee to suppose that no other
nilEvent can be returned before your timeout. That's not part of the deal.
Basically, passing a timeout to EvtGetEvent puts a cap on how long you will
have to wait. It does not promise that nothing will happen sooner.
Said another way, the conceptual error is in interpreting the nilEvent as
"nothing happened" -- that's wrong. nilEvent just means there's no other
type of event that would be appropriate for what did happen. (Usually what
happened is a timer expired.)
--Bob
