|
The information in this article applies to:
- Standard, Professional, and Enterprise Editions of Microsoft Visual
Basic, 16-bit and 32-bit, for Windows, version 4.0
- Standard and Professional Editions of Microsoft Visual Basic, version
3.0, for Windows
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
- If you are using Visual Basic 3.0, make sure that you are using the
updated MSComm.VBX, dated 5/12/93. If you do not have the updated
MSComm.VBX, you can download MSComm.Exe, a self-extracting file, from
the following services:
- Microsoft's World Wide Web Site on the Internet
On the www.microsoft.com home page, click the Support icon
Click Knowledge Base, and search for Mscomm.exe
Open the article, and click the button to download the file
- Internet (anonymous FTP)
ftp ftp.microsoft.com
Change to the Softlib\Mslfiles directory
Get Mscomm.exe
- The Microsoft Network
On the Edit menu, click Go To, and then click Other Location
Type mssupport
Double-click the MS Software Library icon
Find the appropriate product area
Download Mscomm.exe
- Microsoft Download Service (MSDL)
Dial (206) 936-6735 to connect to MSDL
Download Mscomm.exe
For additional information, please see the following article(s) in the
Microsoft Knowledge Base:
ARTICLE-ID: Q101944
TITLE : UPD: New MSCOMM Control Available
- If you are using Windows for Workgroups 3.11, obtain the updated version
of SERIAL.386 by downloading WG1001.Exe, a self-extracting file, from
the Microsoft Software Library (MSL) on the following services:
- Microsoft's World Wide Web Site on the Internet
On the www.microsoft.com home page, click the Support icon
Click Knowledge Base, and search for WG1001.EXE
Open the article, and click the button to download the file
- Internet (anonymous FTP)
ftp ftp.microsoft.com
Change to the Softlib\Mslfiles directory
Get WG1001.EXE
- The Microsoft Network
On the Edit menu, click Go To, and then click Other Location
Type mssupport
Double-click the MS Software Library icon
Find the appropriate product area
Download WG1001.EXE
- Microsoft Download Service (MSDL)
Dial (206) 936-6735 to connect to MSDL
Download WG1001.EXE
ARTICLE-ID: Q112418
TITLE : BUG: Serial Port Driver for WFW 3.11 Sends Extra Byte
- Use the Windows Accessories Terminal application (HyperTerminal in
Windows 95) 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.
- 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.
- 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).
- 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 Interval property to 55 for best performance. (The default of
1000 is too long.)
- Set the InputLen property to 0 unless there is an overriding reason not
to.
- 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.
|