> 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).
Well, you could try it at least! I don't have much experience here so I can't recommend any best solution. > 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. Actually, if the comms HANDLE would get signalled when some event has happened, then you could use WaitForSingleObject( ) directly on it. But at least it doesn't seem to be the case... ------------- Ehsan Akhgari List Owner: [EMAIL PROTECTED] [ Email: [EMAIL PROTECTED] ] [ WWW: http://www.beginthread.com/Ehsan ] Light without eyes illuminates nothing.
