Jim, Patrick,

One more thing though. I just read Patrick's reply. The VFPCOm utility is new to me. I downloaded it and read the docs, so I think I understand the idea of binding the OLE control ONComm event to an equivalent vfp event method. So now I realize that my original question, where I asked if I would need to 'call' the equivalent vfp method was dumb, since the idea is, as I understand it, that when the OLE control's oncomm event fires, so will the vfp equivalent. But even so, I still don't understand why I need it.


So, if I am dropping the control on a form can't I just put the custom oncomm code into the oncomm method directly? If I am doing it in code only can't I just directly subclass the ole control, and put in my own custom oncomm method code. (I think I ready something about the specifics of subclassing OLE Controls in Egger's book - I need to dig that out)

Also, if you could clarify the OOP issue, regarding why it isn't very OOPy to put the processing in the Oncomm event (if I understood that correctly).

TIA


>Patrick,
>
>You are correct if you are placing the control on a form, the event fires nicely. Look at my code - no form, no textbox, nada. Try it for yourself :>)
>
>UPDATE:
>
>You are also correct about the looping - assuming all your processing code is maintained within the ONCOMM event. Others here have convinced me that this is not very OOPy - "Events call methods" is I believe the phrase. So I tend to keep the code very tight in that event - grab the data, stuff it away somewhere, deal with it later. Works for me.
>
>>PMFJI -
>>
>>yep, the MSCOMM32.OCX is a good way to go, but you don't really
>>need the VFPCOM utility to bind events, because the MSCOMM32
>>control already has an event that fires every time it receives
>>a character. that event is the "OnComm" event. all you need
>>to do is to react to that event on every received character
>>and buffer (them) somewhere, and when your received character
>>is CR and/or LF, send your entire buffer to the textbox, and
>>clear the buffer. no need for any looping to check the MSCOMM32
>>control status either, since the event fires asynchronously.