Shouldn't 'ReadFile' block when timeouts are specified ???

  • Thread starter Thread starter ORC
  • Start date Start date
O

ORC

Shouldn't 'ReadFile' block when timeouts are specified even when running in
overlapped mode or am I wrong ???

Thanks
Ole
 
ORC said:
Shouldn't 'ReadFile' block when timeouts are specified even when running in
overlapped mode or am I wrong ???

ReadFile being what, exactly? It's not coming up in the MSDN index...
 
Sorry - the readfile is an API call but I write my application in C# and
don't know where else to place my question. The readfile is implemented
through P/Invoke. I have set the COMMTIMEOUTS (also part of the API) to
wait 2 seconds before timeing out during a call to readfile.

Thanks
Ole
 
ORC said:
Sorry - the readfile is an API call but I write my application in C# and
don't know where else to place my question. The readfile is implemented
through P/Invoke. I have set the COMMTIMEOUTS (also part of the API) to
wait 2 seconds before timeing out during a call to readfile.

Ah, right. This is under the Compact Framework, correct? If so, I'd ask
in either one of the PocketPC groups, or the Compact Framework group.
There are likely to be more people with experience of the function
there.
 
no it's not part of compact framework or a pocket pc - it's part of .NET and
C#. I've looking for a windows API group but such one doesn't seems to exist
any suggestion?

Thanks
Ole
 
ORC said:
no it's not part of compact framework or a pocket pc - it's part of .NET and
C#.

ReadFile itself isn't part of either C# or the .NET framework. When I
found ReadFile in the MSDN after removing the filter, it only came up
with WinCE references. Are you saying it's part of the "normal" Win32
as well? Maybe there are bits of MSDN I haven't installed...
I've looking for a windows API group but such one doesn't seems to exist
any suggestion?

The .interop group, perhaps?
 
AFAIK, the timeouts in the COMMTIMEOUTS structure set using SetCommTimeouts
apply only to serial ports. And even then, the overlapped operations will
never block, just return an ERROR_IO_PENDING. If you need a timeout, you
should wait on the overlapped event using the WaitOne() or similar function.

HTH,
Stefan

ORC said:
no it's not part of compact framework or a pocket pc - it's part of .NET
and
C#. I've looking for a windows API group but such one doesn't seems to
exist
any suggestion?

Thanks
Ole
 
Thanks Stefan,

I'm using the readfile for the serial port in a very simple way: readfile
must block until all characters are read or until the timeout period is
reached but it must not block the writefile. Does any one have a very simple
code example on how to let the readfile block in overlapped mode like with
the suggested WaitOne function ??+

Thanks,
Ole

Stefan Simek said:
AFAIK, the timeouts in the COMMTIMEOUTS structure set using SetCommTimeouts
apply only to serial ports. And even then, the overlapped operations will
never block, just return an ERROR_IO_PENDING. If you need a timeout, you
should wait on the overlapped event using the WaitOne() or similar function.

HTH,
Stefan
 
I guess you should avoid using the overlapped functions from C# at all.
You'll become responsible for pinning buffers, etc... I guess you should use
the FileStream, which is more or less a wrapper of the ReadFile/WriteFile
functionality. However, it doesn't have a wrapper for the CancelIo method
(not one I'm aware of), so you could possibly run into problems with
stopping the long-running read operation after your timeout expires. As for
the timeout, just issue a BeginRead() and start some timer along with it. If
the timeout expires sooner than the read operation is complete, it's up to
you what to do next...

HTH,
Stefan
 
Errr... sorry, I missed that you're using it for serial port access. One way
to do what you want could be creating a FileStream with a handle to the COM
port created by CreateFile. I've heard of this, but I don't know if it
works. For another way (and probably forward-compatible with .NET 2.0), see

http://tinyurl.com/2ce6a

This is a quite old serial port wrapper from MS. It's buggy, but you usually
can work around most of the issues. It worked fine for me. It should work
well in your case, because you can freely combine synchronous / asynchronous
calls with this one (synchronous calls are in fact implemented roughly as
Begin...()/End...()).

btw., be careful about the memory leak mentioned in the discussion on the
component. I haven't met with it, but it surely is there.

HTH,
Stefan
 
Thanks Stefan,

Have now downloaded the wrapper and will have a closer look at it.

Best regards
Ole
 
Back
Top