🚀 go-pugleaf

"Neil P." <nporve01@hotmail.com> wrote in message
news:427fd0af@newsgroups.borland.com...

> Well, I am using overlapped I/O.  The problem is that I don't
> want my code to lock up.

The thing about overlapped I/O is that you don't have to lock up your code.
Once you call ReadFile(), specifying an OVERLAPPED structure, ReadFile()
will return immediately and your code can go off to do other things while
the reading happens in the background.  Then your code can periodically
check the status of the event object inside the OVERLAPPED structure when it
has a chance to.  Once the event has been signaled, the reading has finished
and you can use GetOverlappedResult() to find out the result of the reading.

> If the other unit does not respond, I want the read function to quit,
> but what is a good time to quit?

Your use of CheckCommStatus() to poll the serial port status could be
slowing the code down.  If you get rid of it entirely and just let the
overlapped I/O do the work for you, you'll probably notice that your unit's
responses come through a lot faster.  You know that the unit should be
sending a byte back to you, so just perform an overlapped reading
immediately after you finish writing, and you will still be able to detect
when the reading has completed.

> How about if I dishout an application that works well with this unit,
> under the environment I am in, but when the user gets it, the unit or
> my application seems that it is lockout

That would suggest to me that your code is not set up to handle the serial
port properly.

> because he/she has a pentium 100, operating on Win95

Overlapped I/O on a serial port works fine on Win9x.


Gambit