MSComm OnComm event (Input InBufferCount)
I'm trying to understand this OnComm event code. I'm using someone else's code and I need to know what it's doing. I do understand most of it but here's the questions I do have.
Why is stComChar declared with * 1 ?
A CommEvent must be capable of being events other than recieve events. In this code we only trap for the "comEvReceive" event, correct?
When the comEvReceive event fires, the incoming data is only 1 character? So we keep holding each character until a CR is detected?
After processing all incoming data, the InBufferCount is clear until another OnComm event is fired? Does the OnComm event (or shall we say the com device) send an InBufferCount every time it fires?
Private Sub comm1_OnComm()
Static stEvent As String 'storage for an Modem event
Dim stComChar As String * 1 'temporary storage for received comm port data
Select Case comm1.CommEvent
Case comEvReceive ' Received RThreshold # of chars.
Do
stComChar = comm1.Input 'read 1 character .Inputlen = 1
Select Case stComChar
Case vbLf 'Ignore linefeeds
Case vbCr 'The CR indicates the end of the Receive String
If Len(stEvent) > 0 Then
ProcessEvent stEvent 'Process the Modem event
stEvent = ""
End If
Case Else
stEvent = stEvent + stComChar 'Save everything between CR's
End Select
Loop While comm1.InBufferCount 'Loop until all characters in receive buffer are processed
End Select
Why is stComChar declared with * 1 ?
A CommEvent must be capable of being events other than recieve events. In this code we only trap for the "comEvReceive" event, correct?
When the comEvReceive event fires, the incoming data is only 1 character? So we keep holding each character until a CR is detected?
After processing all incoming data, the InBufferCount is clear until another OnComm event is fired? Does the OnComm event (or shall we say the com device) send an InBufferCount every time it fires?
Private Sub comm1_OnComm()
Static stEvent As String 'storage for an Modem event
Dim stComChar As String * 1 'temporary storage for received comm port data
Select Case comm1.CommEvent
Case comEvReceive ' Received RThreshold # of chars.
Do
stComChar = comm1.Input 'read 1 character .Inputlen = 1
Select Case stComChar
Case vbLf 'Ignore linefeeds
Case vbCr 'The CR indicates the end of the Receive String
If Len(stEvent) > 0 Then
ProcessEvent stEvent 'Process the Modem event
stEvent = ""
End If
Case Else
stEvent = stEvent + stComChar 'Save everything between CR's
End Select
Loop While comm1.InBufferCount 'Loop until all characters in receive buffer are processed
End Select
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I do have the ProcessEvent function under control. In fact, the code I posted works very well. It's just there's a few parts of it that didn't make sense and I don't like to use code I don't understand.
I've developed a feature that checks Com ports for available modems, then checks to see if they are CallerID compatible. There is no sure-fire way of knowing if the modem is truly CallerID compatible and/or enabled, at least not for all modems. But you can give the user a pretty good idea using the code I've developed.
Then you can enable your modems (my code supports 2 of them) to monitor your lines for incoming calls. The process event logs the caller's information, then checks to see if it is a customer in the database. If so, there is a feature that can be enabled that pops up that caller's information. It all happens fast enough that you can see that caller's info. by about the second ring. The bad part is that monitoring the modem makes that modem unavailable for any other application to use. I wish there was some cost-effective way of "passively" monitoring the modem.
This is probably old hat for all you other access programmers but if someone wants the code I'd probably be willing to release. For free. Thanks to all the experts at EE for their tireless assistance. -HK
I've developed a feature that checks Com ports for available modems, then checks to see if they are CallerID compatible. There is no sure-fire way of knowing if the modem is truly CallerID compatible and/or enabled, at least not for all modems. But you can give the user a pretty good idea using the code I've developed.
Then you can enable your modems (my code supports 2 of them) to monitor your lines for incoming calls. The process event logs the caller's information, then checks to see if it is a customer in the database. If so, there is a feature that can be enabled that pops up that caller's information. It all happens fast enough that you can see that caller's info. by about the second ring. The bad part is that monitoring the modem makes that modem unavailable for any other application to use. I wish there was some cost-effective way of "passively" monitoring the modem.
This is probably old hat for all you other access programmers but if someone wants the code I'd probably be willing to release. For free. Thanks to all the experts at EE for their tireless assistance. -HK
ASKER
I failed to notice the following settings that get set when I "connect" to my modem:
comm2.DTREnable = True
comm2.RTSEnable = True
comm2.RThreshold = 1 ' Generate a receive event on every character received
comm2.InputLen = 1
Now I see why we are processing 1 character at a time.
comm2.DTREnable = True
comm2.RTSEnable = True
comm2.RThreshold = 1 ' Generate a receive event on every character received
comm2.InputLen = 1
Now I see why we are processing 1 character at a time.
Sure must be cpu hungry then. I know Access is pretty crap at that. I run queries, that may take time to run, it slows down my PC a fair bit (well at work that is!!!)
I guess thats why u need DoEvents in your code to help out a little
I guess thats why u need DoEvents in your code to help out a little
ASKER
Is there an option to do otherwise? Does data "stream" in one character at a time?