Overlapped IO

In the context of serial communications the term 'Overlapped IO' is where a function call, such as one that sends data, will return immediately while the actual trasnmission of the data continues in a background process.

For example sending a long string of data at a low baud rate can often take a few seconds and if your application was forced to wait then it would appear to hang. Even small amounts of data at very high baud rates will make an application seem very unresponsive.

Our Comm32 OCX is intended to be a direct replacement for Microsoft's MSComm32 component.

But Comm32 is not MSComm32.

After all, you're looking for an alternative so there's something in MSComm32 that you don't like so what would be the point if our OCX was an exact replica of MSComm32?

You'll notice that our OCX has a few properties and functions which you didn't have with MSComm32. The name of most of them gives a clear indication of the functionality but we'll discuss a couple of important ones here.

ParallelEnable

Don't be confused by the name. It has nothing to do with Parallel ports.

Before going into detail about this property we'll talk about a specific 'feature' of MSComm32.

When you use MSComm32 Output property your data is written to the OutputBuffer and control returns immediately to your application allowing your application to do some other processing while MSComm32 sends your data in a background thread.

If you're creating an event driven application then that is the behaviour you want. You can get on with some other work and MScomm32 will inform you via the OnComm event when your data has been sent.

But if you're not creating an event Driven application then perhaps you'd rather that your application was forced to wait until the data has been sent before carrying on with the next line of your code.

MSComm32 does not give you the choice but it's not consistent either. Sometimes it returns immediately and other times it will hang untill all the data has been sent - and in some cases it will hang forever !!. By the way, that's not a bug. It's intentional. Microsoft designed it that way on purpose. We could explain it but we're not here to discuss MSComm32 in too much detail.

Because MSComm32 is not consistent we decided to add a property - ParallelEnable - which forces our OCX to behave one way or the other so you know what to expect.

ParallelEnable = True

The default. All Output properties and functions return immediatly and your data is sent in a background "Parallel" thread. When transmission is complete you'll get the OnComm event as expected.

ParallelEnable = False

Disables the parallel thread so the output properties and functions do not return until the data has been sent.

Without making this page too long we need to explain just one more property. TxTimeout. MSComm does not have such a property. Well, actually it does. It's just permanently set to MAXDWORD (Forever). We didn't like that so we decided to give you more control.

When ParallelEnable is true all output functions return immediately meaning that TxTimeout is ignored.

When ParallelEnable is false the output functions do not return until the data was sent or untill it times out (The TxTimeout period elapses)

Be carefull with the timeout property. If set to zero then this is the same behaviour as MSComm32 never timeout) but if set too low then the output function might return before all your data was sent causing some data to be discarded.

Summary

MSComm32 Output property should - but often doesn't - return before the transmission is complete.

Comm32 gives you the ParallelEnable property to force the behaviour one way or the other. If you decide to set ParallelEnable=False (Wait until transmission is complete before returning) then you also have the TxTimeout property so that, in the event of a flow control hang up, it doesn't wait too long and hang your application.

When using TxTimeouts with ParallelEnable=false we would recommend that you use Comm32 WriteString or WriteBytes functions instead of the Output property.