Hi Patrick,

Oh I think we may be on the same page. :>) And your approach is sound. If we go back to the original post, David was having problems with the original textbox, retaining focus. It sounded like he did not need any user interface/interaction. In fact, that was getting in the way. My solution showed how to handle the problem with no stinking form or textbox.

>Jim -
>i'm not sure, but i think we are agreeing here :)
>it sounded like he _would_ have a form, since he mentioned a
>textbox. on each received character, i'd append the just-
>received character to a form-level buffer. when the received
>character is the delimiter, assign
>

>THISFORM.txt_My_Text_Box.VALUE = ALLTRIM(THISFORM.str_My_Buffer)
>

>in the txt_My_Text_Box.ProgrammaticChange event deal with
>the data as necessary (which is likely to be the bulk of code).
>that's about as minimal as you can get in the OnComm event.
>

That looks like a good approach. Now, how about creating an ASSIGN method to watch THISFORM.str_My_Buffer and I can still toss the textbox out :>)

>i didn't realize the events fired differently whether or not
>it was on a form. does that mean the DLL and the OCX are
>implemented slightly differently ?

It is not a matter of different - it is working vs nonworking. Check up the thread to that Wiki link I posted for the discussion. If you need a visual interface, by all means create a form and drop the control on it and you will not have problems. MSCOMM32 is one of those Activex controls that want to reside in a container, preferrably a form (I haven't tried others). My example shows that with VFPCOM's bindevents() allows me to bypass that requirement. Add the Winsock control to the mix, and now I have a black box, no visual interface, that can transfer serial data to and from a device to anywhere on the planet. Are there better/more suited ways to do this? Sure. But I already have VFP and the controls are free :>)