Forum Index > Comm64 Event TImeout

By: Guest Posted on: Apr 11 2015 at 09:51:43 AM

In the Comm64.COMMEVENTS enum are missing all the MSComm Error Timeut events: comCDTO - comCTSTO - comDSRTO. Is there a way to intercept such erros or they fall in the "generic error category"?

By: Guest Posted on: Apr 13 2015 at 06:55:53 PM
What do you expect such an event to tell you? Under what circumstances would the serial port raise such an event?

By: Guest Posted on: Apr 14 2015 at 07:55:32 AM
I am planning the replacement of the MSCOMM ActiveX control in a .NET code, and
I have noticed that your object does not expose these enum values. So, for a complete replacing, how can I intercept such error messages?

By: Matt Posted on: Apr 14 2015 at 08:20:18 PM
Those events do not exist in MSComm32. If they do exist then they are hardware or application specific.

Please give an example of what you would do with such an event? I mean how on earth could CTS timeout ?

So, as the previous guy asked - under what circumstances would the serial port raise such an event?

By: Guest Posted on: Apr 14 2015 at 09:04:45 PM
1002, 1003 and 1007 (the ComCTSTO and the others, dsr and dcd timeout events) are not mscomm32 events. They are MSComm16 events. They're deprecated since windows NT.

Even if you do write code to handle those events i dont think mscomm32 would ever actually raise them.

By: Guest Posted on: Apr 15 2015 at 11:51:34 AM
Thanks for the info.
This means thar probably the VB6 code that I'm viewing is and update of an old VB3/4 16 bit.
Thanks again.

By: John o'groats Posted on: Apr 16 2015 at 08:35:37 PM
Actually Matt, the constants for the cts, dsr and dcd timeout 'do' exist in MSComm32 but i think we should consider them deprecated seeing as how mscomm32 doesn't actually offer any timeout options anyway.

But to answer your question "when would port raise such an event". In the old days the comm control would raise a comCTSTO event if you attempted to transmit data while transmission was blocked by rts/cts flow control. Basically if transmission remained blocked for n milliseconds then the transmission would be aborted and the comCTSTO event would be raised. That sounds kind of cool untill you think about it a little. If transmission was aborted theres no way of knowing how many characters were discarded - ie did some get through before cts changed? So, all in all, even in the old days, the event wasn't much use.

Nowadays you queue data into the transmit buffer and, if flow is blocked by cts, the data sits in the transmit buffer forever and you'll be notified by the evSend event once the data has been successfully sent.

Which brings me to what i think is a bug in MSComm32. If you queue a load of data into the tx buffer and transmission remains blocked for an extended period i have observed that MSComm32 discards one byte every 30 seconds. I haven't researched this much so ot may be related to OS version or type of com port - but, happlily sComm32 and Comm64.dll do not suffer from that.


Reply - add comment to this topic
You may enter letters, numbers and standard punctuation only. HTML and other scripts/tags will be rejected
  Topic:- Comm64 Event TImeout

Your Name


Forum scripts and databases - Copyright (c) 2009 - 2012