> A leap in the dark: does SetCommTimeouts( ) affect WaitCommEvent( ) > behavior? If it does, it's trivial to write a function like > WaitForSingleObject( ) which first sets the comms timeout, and then waits > for a comms event.
Unknown. The comms chapter in MSDN talks about its use for ReadFile(), WriteFile(), ReadFileEx() and WriteFileEx(), but not for WaitCommEvent(), although it does talk quite a bit about synchronising. I'm not sure whether ReadFile() with a timeout or WaitCommEvent() and process on EV_RXCHAR are better - whether either of them has any long-term impact. I chose WaitCommEvent() simply because it's more in keeping with the concept of a dumb character receiver rather than waiting for a specified number of characters to be received (although, of course, I could quite happily issue another ReadFile() to get more). Wouldn't WaitCommEvent() be doing much the same thing as WaitForSingleObject()? Both waiting for something to happen without tying up the thread? The only difference I can see is that WaitForSingleObject() would wait until an entire buffer had been transmitted / received, whereas WaitCommEvent() waits until just one character is received. If we knew what packet size we were expecting then the latter should surely be more efficient, but since this control has no concept of a packet size (by intention), it doesn't seem to make much difference. -- Jason Teagle [EMAIL PROTECTED]
