OK. I think I've got the concepts down now. I can see why you have put it together the way you have, and why vfpcom is need.

BTW, in this case I will probably instantiate it from a form. But I will probably need the control without a form down the road for some other uses.

Thanks again!

>More comments inline:
>
>>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.
>>
>
>Go to http://fox.wikis.com/wc.dll?Wiki~MsComm32~VFP for confused discussion of this topic. Andrew Coates sums it up fairly at the beginning - the event will not fire unless the control resides in a form. VFPCOM allows us to use the control with no form or GUI. You could programmatically create a form, add the control, etc. as per the example in MSKB #Q291535 , and just notshow the form. Your call. As you said that your had no need for a visual interface, I gave you the smallest bit I could. It is another DLL to distribute, however.
>
>>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)
>>
>
>Give it a try. Tracey Holtzer and I went around with this issue a while back and could not get a subclass to fire in this way period. Maybe you will have better luck :>) From the above example:
>

>DEFINE CLASS MSCOMM_OCX AS OLECONTROL
>             OLECLASS = [MSCOMMLib.MSComm.1]
>ENDDEFINE
>

>Even Microsoft isn't subclassing it :>)
>
>>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).
>>
>
>http://fox.wikis.com/wc.dll?Wiki~EventsShouldAlwaysCallMethods~SoftwareEng
>
>Since you have a PUTM, try a search here on that phrase "events call methods" - others far more knowlegable than I have stated their reasons for this. For me, it is just a cleaner way to maintain the app. The ONCOMM event should do one thing - empty and save the port buffer, then have someone else figure out what to do with it. Try putting a SUSPEND into the event and soon you will see the problems. Much easier in a form method or procedure.