>Thanks Ed. Yes, I did read the MSDN docs and used their example. RThreshold is effectively set at 1 char. But the first time OnComm() fire, I get the whole string from the Input property, not just one char. OnComm() will fire many times after than, with CommEvent = 2, but the Input property is empty.
>
Yep - each character received will queue a comEvReceive, since RThreshold = 1. Even if you grab 40 characters in the first pass from .Input, the event fired 40 times.
>If it were just that, I would be happy. The problem I'm having now, is that the OnComm() event doesn't fire sometime. I would get PC "A" sending a string many times to PC "B" and PC "B" OnComm() event won't fire at all. It's not constant, one time it doesn't work, I close all and restart the communication and then it will work (or the other way around). I have used your suggestion in another thread to use the VFPCOM.BindEvents(), it have improved things, but I'm still having some problems.
>
>Is it the MSCOMM component that is buggy or is it VFP that doesn't work well with it? Why do we need VFPCOM.BindEvents() to make it work? Would I have the same problems if I redo the same component in VB?
Depending on what besides picking up characters from the comm port is going on, VFP may not be responding to the OnCOmm event in a timely fashion; VFP can't interrupt a single, atomic line of VFP code to service an event, whether from MSCOMM or the UI - run a long reindex or query and watch timers, mouseclicks, etc. get ignored until the single line of code completes. I've found that in compute-intensive loops, periodically issuing a DOEVENTS will force VFP to check for pending events more reliably; with tight loops, events seem to get lost without it.
My use of MSCOMM for event-driven comm has been limited to low-speed, low-volume, intermittent applications - reading a scale, writing to a slow control device, etc. If I need to do anything serious as far as low-level comms, I go to another language like C that's better suited to the task and write the comm portion of the application there, and then use VFP as an out-of-process COM server accessed from my communications application to get database functionality.
>
>TIA
>
>>There are a number of events besides the receipt of a character that trigger the OnComm event; take a look at the OnComm Event example in the MSDN docs (yeah, they're in VB...but it's easy enough to figure out.) If the RThreshold set for the comm instance is one character, then it'll be triggered once per character received. If the port senses a change in the port being ready to send, it'll pop the OnComm event. The trick is to only respond to events that you've an interest in, and ignore everything else.
