Remarks: If a serial port did not support overlappedIO -
when you place data into the transmit buffer - your application would hang until all the data has been transmitted. In practice this might only be for a few ms but, if data was held up by flow control, it could be quite a while causing the application to become unresponsive.
When OverlappedIO is enabled the output method will return immediately and the asynchronous thread in the windows com driver transmits your data in the background. This allows your application to remain responsive even under heavy load and/or adverse flow control conditions.
When using the OnComm event to create an event driven application you would be notified via the OnComm event when the transmission is complete.
If you do not wish to use OnComm events then you can read the OutBufferCount property to detect when the transmission is complete.
How Is this different to MSComm32 ? MScomm32 also uses OverlappedIO although if you attempt to queue more data while a previous overlapped operation is pending then the output method might not return (Your application locks up) until all write operations are completed. In effect this means that MSComm32 might only allow one overlapped operation preventing you from queuing more data until the previous output is complete.
Using our SComm32 ocx that limitation does not apply and you can continually insert data into the output buffer - although you should of course monitor the OutBufferCount to ensure that you have space in the output buffer.
There are few cases where you might wish to disable OverlappedIO. For example if you were developing a time critical polling protocol or simply sending small packets of data in a tight loop then it might be beneficial to disable OverlappedIO and then you would know that the Output method only returns when your data has been sent.