INFO: Troubleshooting Tips for the MSComm Control

ID: Q192012

The information in this article applies to:

Microsoft Visual Basic Learning, Professional, and Enterprise Editions for Windows, versions 5.0, 6.0
Microsoft Visual Basic Standard, Professional, and Enterprise Editions, 16-bit and 32-bit, for Windows, version 4.0

SUMMARY

The MSComm control encapsulates much of the functionality provided by the communications functions of the Windows API. This encapsulation makes these functions easier to use but does limit the functionality of the MSComm control. This article provides you with some tips for troubleshooting the MSComm control.

MORE INFORMATION

If you are using Visual Basic 6.0, the version that ships on the CD is 6.00.8169. If you are using Visual Basic 5.0, there are two versions of the MSComm control that you can use. Microsoft recommends that you use the version updated by Service Pack 2 for Visual Basic 5.0. This version is 5.01.4319 dated 7/19/97. The other version, which shipped on the Visual Basic 5.0 CD, is 5.00.3714 dated 1/14/97. The major fix in the Service Pack 2 version is documented in Microsoft Knowledge Base article Q171472, and it fixes a memory leak that was occurring when the port was repeatedly toggled open and closed.

Use another communications application such as HyperTerminal, supplied with Windows 95 and Windows 98, to determine if a connection can be established independent of Visual Basic. This will determine if a connection can be made using only the communication functions in the Windows API. If a connection cannot be made, examine the physical elements of the connection. Is the proper cable being used? Is it connected to the correct serial port? If a connection can be made, note the settings that were used and use the same settings with the MSComm control.

Use the Visual Basic VBTerm and Dialer sample applications with the appropriate settings. If these work, use this code as a starting point for your application. If they don't work, first try the suggestions below on these samples. If these suggestions fix the problem, then use the samples as a starting point. Otherwise, start with the simplest code possible and use the following suggestions as a starting point.

Set the RTSEnable property of the MSComm control to True. Many modems and other communication devices use the RTS signal for handshaking.

Set the RThreshold property to 1. If you set the RThreshold property to any other value, you may have trouble unless all of your data consists of fixed-length packets.

Set the InputLen property to 0 unless there is an overriding reason not to do so.

Always receive data when data is available. Do not rely on the RThreshold property to tell you if data is available. Use the OnComm event procedure. Double-buffer the incoming data. Extract the data from the buffer and process it. Clean up the buffer to remove the processed data. For example:
```
      Sub MSComm1_OnComm()
         Static Buffer As String

         ' Always buffer incoming data no matter
         ' what generated the OnComm event.
         Buffer = Buffer &amp; MSComm1.Input

         ' Check if buffer has grown larger than limit.
         If Len(Buffer) >= limit Then
            ' Call procedure to Process the received information.
            process Left$(Buffer, limit)

            ' Clean-up buffer
            Buffer = Right$(Buffer, Len(Buffer) - limit)
         End If
      End Sub
 
```
This procedure double-buffers the received data and, unless the program is bound to fail because of some other performance problems, provides good security for the received data. It is extremely important to handle every character as it comes in at high baud rates. If you are looking for a terminating character sequence instead of length, then the test would use InStr instead of Len.

Whenever possible, use event-driven communications. A template for the OnComm event can be found in Help under the example tab of the OnComm topic. Event-driven communication is far more efficient than continuous polling, and also allows for a wider range of error handling.

========== 16 bit only ==============

If you are using Windows for Workgroups 3.11, obtain the updated version of SERIAL.386.

The following file is available for download from the Microsoft Software Library:

~ WG1001.exe
For more information about downloading files from the Microsoft Software Library, please see the following article in the Microsoft Knowledge Base:

Q119591 : How to Obtain Microsoft Support Files from Online Services

If the Visual Basic application using the MSComm control is running on a Windows for Workgroups 3.11 machine with a 16550AF UART chip and the InBufferSize property is greater than 1024, COMxFIFO=0 must be added to the [386Enh] section of the System.ini file. This entry disables the FIFO buffer of COMx's 16550 UART. If a serial port does not have a 16550 UART, this setting is ignored. The default value is 1 (enabled).

Additional query words: kbDSupport kbDSD kbVBp kbVBp400 kbVBp500 kbVBp600 kbCtrl kbfile
kbsample kbComm

Keywords : kbGrpVB
Version : WINDOWS:4.0,5.0,6.0
Platform : WINDOWS
Issue type : kbinfo