Knowledge Base

INFO: Troubleshooting Tips for the MSComm Control

Article ID: 143113

Article Last Modified on 8/5/2004

APPLIES TO

This article was previously published under Q143113

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. Here are some tips for troubleshooting the MSComm control.

MORE INFORMATION

  1. If you are using Visual Basic 3.0, make sure that you are using the updated MSComm.VBX, dated 5/12/93.The following file is available for download from the Microsoft Download Center:

    MSComm.exe

    Release Date: October 27, 1999

    For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:

    119591 How to Obtain Microsoft Support Files from Online Services

    Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file.
  2. 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 Download Center:

    Wg1001.exe

    Release Date: May 31, 2000

    For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:

    119591 How to Obtain Microsoft Support Files from Online Services

    Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file.
  3. Use the Windows Accessories Terminal application (HyperTerminal in Windows 95 or 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 can not be made, examine the physical elements of the connection. Is the proper cable being used? Is it connected to the serial port? If a connection can be made, note the settings that were used and use the same settings with the MSComm control.
  4. 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.
  5. Set the RTSEnable property of the MSComm control to True. Many modems and other communication devices use the RTS signal for handshaking.
  6. 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).
  7. 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.
  8. Set the Interval property to 55 for best performance. (The default of 1000 is too long.)
  9. Set the InputLen property to 0 unless there is an overriding reason not to.
  10. Always receive data when data is available. Don't 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 Comm1_OnComm ()
       Static ReceiveBuffer As String
       ReceiveBuffer = ReceiveBuffer & Comm1.Input
       'Always buffer incoming data no matter what generated the OnComm
       'event.
       If Len(ReceiveBuffer >= Limit) Then
         Call Process(Left$(ReceiveBuffer,Limit))
         ReceiveBuffer = Right$(ReceiveBuffer, Len(ReceiveBuffer) - Limit)
         'Cleans-up buffer.
       End If
    End Sub
    'If you are looking for a terminating character sequence instead of
    'length, then the test would use InStr instead of Len.
    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.

REFERENCES

If the MSComm control is not satisfactory, the communication APIs available in Windows may provide the necessary solution. Daniel Appleman's "Visual Basic Programmer's Guide To The Windows API" book is an excellent resource for the 16-bit communications APIs as is the VBComDem sample (Q75856). For information on using the 32-bit communications APIs see "Create Communications Programs for Windows 95 with the Win32 Comm API" in the December 1994 issue of the Microsoft Systems Journal.

Additional query words: Wg1001

Keywords: kbinfo kbdownload kbapi kbvbp kbvbp400 kbctrl kbgrpdsvb kbvbp300 KB143113


Send feedback to Microsoft

© Microsoft Corporation. All rights reserved.