>>If I read the above correctly, the host is trying to send you 3 pages of data, and messing with the keyboard in the meantime. 3 pages @ 80X25 = 6000 bytes going somewhere. I think you have insufficient buffer space and/or handshaking problems. As a test can you drop back to 300 bps to see if any more data becomes available? I think you are transmitting the control sequence fine, just dropping the data inbound. Others have reported problems with the control being unreliable - see here - http://fox.wikis.com/wc.dll?Wiki~MsComm32~VFP . I haven't experienced the problem, using hardware handshaking, allocating sufficient buffer space, and keeping the Oncomm event code very tight. Any massaging of the data should be done elsewhere.
>

>Jim,
> Following your idea, this is finally starting to make some sense. The first thing I tried was setting the receive buffer to 30270. This yielded the same result as before, so I tried backing off the speed a little. At any speed other than 9600, all data coming back is unreadable, I'm not sure what I'm looking at.

By backing off on the port speed, did you also set back the DEC side? I may be saying the obvious, but... Guessing that my read on the control stuff is correct, set the buffer to 8k.

> This gets kinda weird. I shut off handshaking altogether, but it seemed to make no difference.

Which tells me you have no handshaking whatsoever. Just because you issue and XOFF to tell the transmitter to stop sending, there is no guarantee that it will be respected.

>I don't know what else to try, but after looking at your analysis of the returned data, I'm pretty positive we're on the right track now. Let me know if you got any other thoughts I could try.

OK, go into your form, select the comm control and hit F1. Go to the example for the Oncomm Event. Let's try building a similar CASE/ENDCASE structure around your Oncomm event code to trap for some typical errors - buffer overflow, framing error, etc. The example is in VB but you'll get the idea. Nothing more than a MESSAGEBOX() would be OK for troubleshooting. Want to get fancy, use your FCREATE/FOPEN/FWRITE abilities and dump your own messages to a text file.

Try bumping up your RThreshold value so you aren't hitting the Oncomm quite so heavily. Let a bit of data build up first.

Getting drastic now. Go to a polling method. Issue your F2 sequence, fire a timer for say 2 seconds, then poll the port and see if all your data is there now. I have no clue how this might affect the rest of your application but we are getting desperate.

Instead of going directly to an editbox, try creating an array, switch the control to binary mode, and do your THIS.Input to the array. You are totally on your own here. :)

Try implementing the VFPCOM BindEvents thing referenced at the Wiki site. You might be one of those affected.

Let me know what model DEC you have and the OS/version. Also the OS/version you are developing on.

> I'm going to take a closer look at some of the other settings of this control. If anything else pops up, I will let you know. Thanks again, this is really helpful, I appreciate all the time you are taking with this.

My first VFP (version 3) app used serial communications extensively. To say I got my hands dirty would be an understatement.

>It seems as if my vendetta has now become your's as well :)
>John

Well, I haven't seen any murders yet, just a problem to solve. If you wish, let's just go to email with the rest of this. I doubt that anything we are doing here is very useful to the general VFP public. However, we could go on to create the longest thread ever?

And please, please, don't tell me at this stage that this is for a telemarketing application.