Topic: MScomm32 comEvSend event doesn't always fire.
|By: Josh||Posted on: Oct 16 2017 at 11:53:40 AM|
|Just sending data with MSComm32 I get the the OnComm commEvSend event as every time.|
But if doing heavy full duplex I get the evReceive events but then the evSend events stop coming.
I'm sure this never used to happen with Windows XP. Is this something in newer version of windows?
|By: Support||Posted on: Oct 16 2017 at 12:41:39 PM|
|Josh. I'm sure you'll understand that we're not really here to support MSComm32. We'd obviously like to get you using our OCX instead.|
So I'd like to be able to say that your problem is caused by MSComm but, in this case, I really don't think MSComm is at fault here. The problem (yes I have seen it) is lower down in the OS or the device drivers. I've only noticed it when using USB/RS232 devices and some brands/chipsets seem more affected than others so maybe the root cause is in the device's drivers somewhere.
If, using MSComm32, you send some bytes to a remote device and get a reply from the remote device then you'll get the EvSend followed by the EvReceive events quite reliably. But, as you said, in heavy full duplex environments where TX and RX are happening at the same time then it does seem as if one of the events overwrites the other and, when it happens, it always seems to be the evTxEvent that gets lost.
I will add though that our OCX doesn't seem to affected. We use a different 'trigger' to handle TxEvents.
So. I'd suggest trying it with our OCX. In most cases it won't take a minute to get it into your project in place of MScomm.
|By: Josh||Posted on: Nov 3 2017 at 11:20:30 AM|
|Thank you Support. Yes. your control does fix the problem. I just purchased a licence. Thank you.|
But it would be great if you could explain what the problem is with MSComm and how your control doesn't have the same problem. You said the problem is in the driver but in that case why doesn't the same problem affect your control? Sorry about the question. It's just the way I am. I not only ant a solution but I also like to kow why.
|By: Support||Posted on: Nov 3 2017 at 01:01:49 PM|
|Josh. Thank you for choosing SComm.|
I don't like criticising other products, I'd rather talk about our products and let the buyer/user make their own mind up.
But, the 'feature' you describe in MSComm is that it's pretty quick to raise OnComm events. In many cases this is actually a 'Pro' rather than a 'Con'. But it becomes a 'Con' if different events occur close together.
As you said, if you send a message to a remote device and get a reply just like a conversation then there's no problem and MScomm32 should perform just fine.
But if your receiving a constant stream of data using evReceive events and you're trying to send packets of data at the same time using evSend events then problems can occur. Lets say you've just sent some data and MSComm32 sets the CommEvent property to comEvSend. But before your application has time to respond to that event more data arrives and MSComm32 immediately sets the CommEvent property to comEvReceive. Your application meanwhile was responding to what was originally an evSend event but the CommEvent property is now evReceive so your application never saw the evSend event.
The problem is that there's only one CommEvent property and if different events come very quickly then MSComm32 sets the CommEvent property as quickly as the events occur even if your application didn't get chance to read the CommEvent property before it changed.
How is our SComm different? When SComm sets the CommEvent property and raises an OnComm event no further changes will be made to the CommEvent property until your application has responded to, and completed/exited, the OnComm event. If more than one event occurs, even if they occur simultaneously, you will get separate OnComm events for each event.
Reply - add a comment to this topic.
You may enter letters, numbers and standard punctuation only. HTML and other scripts/tags will be rejected.