>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.

Enabling hardware handshaking programs the UART/USART chip, which actually handles the serial communications, to signal and detect the state of hardware handshaking by the USART itself. It's aware of the state of it's own buffer, and when the buffer fill state reaches a threshhold set by one of the control registers, drops either the CTS or DSR line, depending on which type of handshaking is in use. It also is forced to respect the state of the RTS or DTR line as set by the serial device at the other end, so that it doesn't overrun the buffer at the other end. The behavior is automagic; once it's enabled, the USART manages the use of the hardware handshaking lines itself.

There is some tuning that may need to be done, which, in order to get it optimized, requires really detailed knowledge about the serial connection - the 'longer' the physical distance betwseen devices, the more data may be in motion over the link at any given moment. With relatively short distances, typical of most RS-232 links, the distances are quite small, well under a km between the transmitting buffer and receiver (most modems, with the notable exceptions of WinModems, whose inventor should be roasted over an open fire after inflicting several thousand papercuts on them and tossing them in Long Island Sound a couple of time, have an on-board buffer of several hundred to 1K characters, to allow for long transmission line delays) - if you're dealing with direct, unbuffered interfaces that span long distances (for example, a direct satellite link, where the transmission delay runs into the several hundred millisecond range) you may need to adjust the buffer full trigger levels
which is a good indication that you need somewhat more experience in telecomm than just implementing an ActiveX control, because ypu're now required to know the intimate details of the hardware implementing the serial communications. If you're dealing with modem-level programming, or typical RS-232C direct links, this probably isn't an issue with current equipment; the standard USART behavior on most 386 or better class hardware acts like the NS16550 USART, which has a 16 byte buffer on the chip itself, and some of the current DSP implementations have buffers with capacities in the 1KB range. If you are dealing with detailed programming of the USART, VFP is (IMO) not the platform to be programming with; a low-level language like C/C++ is a better platform.