SComm32 Communications DLL.



. Break
. CDHolding
. Commevent
. CommName
. CommPort
. CTSHolding
. DSRHolding
. DTREnable
. EOFChar
. EOFEnable
. EvtChar
. EvtCharEnable
. Handshaking
. InBufferCount
. InBufferSize
. Input
. InputLen
. InputMode
. NullDiscard
. OutBufferCount
. OutBufferSize
. Output
. OverlappedIO
. ParityReplace
. PortOpen
. Read
. RThreshold
. RTSEnable
. Settings
. SThreshold

OnComm Event
Hardware/Cables etc
Loopback Test Plug


Retrieves (reads) data from the receive buffer.


MSComm32 and SComm32 have the same syntax and functionality.


value = SComm1.Input


A String or an Array of Bytes depending on the current state of the InputMode Property


Example reading a character string.

SComm1.InputMode = 0
Text1.Text = Text1.Text & SComm1.Input


Example reading an Array of Bytes.

SComm1.InputMode = 1
dim b() as byte
b = SComm1.Input



The word 'Input' is a reserved word in some modern scripting languages. SComm32 continues to support the standard .Input method for backward compatibility with MSComm32 and in the vast majority of Windows/Forms development environments there shouldn't be any problem using the standard .Input method.

However, if your application does not have a Windows/Forms UI for example if you create the Object and OnComm event in code then, depending on your development environment, you may find that the .Input method won't compile. In such cases you can use the .Read method instead.

Internally both .Input and .Read are tied together giving identical functionality.

The behavior of this property is affected by the InputMode property. You will see from the above examples that both modes can return the same data but how you then process that data depends on whether the data is returned as a string or an array of bytes.