On Feb 3, 2013, at 2:49 PM, Mark Wieder <mwie...@ahsoftware.net> wrote:
> Jacque- > > Sunday, February 3, 2013, 1:51:24 PM, you wrote: > >> On 2/3/13 3:08 PM, Mark Wieder wrote: >>> Jacque- >>> >>> Sunday, February 3, 2013, 12:40:43 PM, you wrote: >>> >>>> In the case of sockets and drivers it is possible to read without error >>>> but not receive all the data due to communication issues. In that case >>>> you'd want to know if the read had paused or had really finished. >>> >>> I was about to post the same, but then Bob would be on my case >>> instead <g>, so I'm glad you beat me to it. I'd be happier if the read >>> command had been written to return the number of characters read, in >>> which case 0 or -1 would be an error, but we're stuck with what we've >>> got. >>> > >> If you're reading a serial port, you don't always know how many >> characters to expect. I'm not sure if that's still the same thing though. > > Yeah, interesting point. I'm not sure what EOF means in that case > either. Is that "I received an EOF char from the port"? I don't think EOF is meaningful with a serial driver. The closest character is Ctrl-D, EOT, end of transmission. I've always had to use read from driver tPort until empty in tTimeout milliseconds and put that in a timed repeating loop, buffering until a "real" return char comes in. .Jerry _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
