>I know how hardware flow control works. I envision using CTS/RTS in my app for flow control. However I am confused on just what exactly the flow control setting does as far as the control is concerned. Does it implement flow control for you behind the scene (looking at the receive buffer)? Or do you have to implement it yourself by controlling the RTS line when inbuffercount reaches inbuffersize? If you have to implement the flow control yourself that is why I question what the setting does.

---

You do not manually control data transfer using CTS/RTS - this is just one of four handshaking options:

comNone        0  (Default) No handshaking. 
comXOnXOff     1  XON/XOFF handshaking. 
comRTS         2  RTS/CTS (Request To Send/Clear To Send) handshaking. 
comRTSXOnXOff  3  Both Request To Send and XON/XOFF handshaking

Handshaking refers to the internal communications protocol by which data is transferred from the hardware port to the receive buffer. When a character of data arrives at the serial port, the communications device has to move it into the receive buffer so that your program can read it. If there is no receive buffer and your program is expected to read every character directly from the hardware, you will probably lose data because the characters can arrive very quickly.

A handshaking protocol insures data is not lost due to a buffer overrun, where data arrives at the port too quickly for the communications device to move the data into the receive buffer. You should only concern yourself with dealing with the Comm Events and not writing to the output buffer if it is full or nearly full. If you do not read from the input buffer (inbound) data transmission should automatically pause because of the handshaking. PS. Hardware handshaking is probably the best (from a performance perspective) option if available.