Actually MSComm isn't a bad component. If your application is quite typical then it's likely that MSComm32 will work just fine - but you're reading this so we're going to assume you have a reason to look for an alternative.

OK, what's wrong with MSComm32 ? Maybe you just want more com ports? As you know, MSComm is limited to 16 ports. Comm32 doesn't have that limitation so it's likely that many people will switch to Comm32 for that reason alone. We've made Comm32 code compatible with MSComm32 so you should be able to drop Comm32 into many existing projects without changing any of your project's source code.

But you may be experiencing other problems. Does any of this sound familiar ?

Applications Hangs - You're sending data but suddenly, for no reason at all, your application appears to lock up. This may only be for a moment but it keeps happening making your application appear unstable. Or maybe it locks up for extended periods or crashes completely forcing you to kill it via task manager.

Data corruption - You're receiving data and all the data is there - it's just mixed up in the wrong order.

Data Loss - In most cases this will be a fault in YOUR programming. MSComm expects you to understand how com ports work and isn't too forgiving. At the slightest opportunity it'll turn round and trash your data. There are however a number of 'features' in MSComm which cause loss of data no matter how good your code is.

Stack Overflow - Now we're going in to too much detail . . . . If you're getting the Stack Overflow error then you have a problem which even good coding might not fix. (Here's a tip - if you're getting Stack Overflow when using MSComm32 then try removing the 'DoEvents' - but if you do that your application becomes unresponsive - you just can't win !)

You can fix many problems with MSComm by knowing a little about how com ports work and making changes to your application. Having said that, there are a number of cases where data loss with MSComm32 is inevitable no matter how good your code is - for example when communicating under strict flow control conditions with slow moving equipment such as manufacturing machinery, robotics etc. MSComm does not like waiting. It gets bored and starts trashing your data.

.... and don't even bother using MSComm32 to do any of that machinery and robotics stuff with com ports attached to remote port servers or thin client terminals

But, even if you could avoid problems with MSComm by changing your code - why should you ? The whole idea of using a ready-made ocx control is that somebody else was supposed to take the time to make a bunch of properties, methods and events allowing you to use com ports without needing to know much about com ports, comTimeOuts and OverlappedIO.

Isn't that what you expect ?