By the way, thanks so much for your help. I did get the project working well enough to show that the problem I was really having was in the scale, not in my port. The issue with doevents is one that I am working to implement and should take care of any remaining issues I had. For now, anyway, everything is working acceptably and the client is taking responsibility for problems with the scale (whew).

Steve

>That is the only one here.
>
>I took a working VFP6 case, using 2 ports and 2 controls, that loop a text file from port to port and back. I created an exact copy, using VFP7 base classes only, from scratch. Compared both forms with Class Browser code view. The VFP7 still will not run, hangs just after starting an output, the second (receiving) control is not responding to events. I'll see today if I can "Fix" it for VFP7.
>
>UPDATE: 2 3rd party .ocx's are also broken... There must be a common denominator.
>UPDATE #2: I retract the NOT working. What took 30-45 seconds to run with a ~100k text file now runs in 15 minutes. No UI updates, CTRL-ALT-DEL show "Not Responding". I have made a single port loopback that I can send out small strings and read back/display without error. I Guess I can't completely fault VFP7 yet...
>
>>Well, I guess for now I'll back down to VFP 6 and see if that helps. Does the mscomm control exist in different places for the two versions of VFP? I did a search and only found mscomm32.ocx in my windows\system32 directory. That would lead me to believe the problem is purely a Fox one if version 6 works with the same control correctly.....