WaitCommEvent -- dotnet compact framework

Ginny Caughey [MVP]
12/29/2005 8:32:39 AM

Hi Graham,

I think when you close the port, WaitCommEvent unblocks. So if you call
WaitCommEvent on a separate thread and have the port handle visible to both
threads, you should be able to close the handle and cause WaitCommEvent to
unblock.

--
Ginny Caughey
..NET Compact Framework MVP

[quoted text, click to view]

Graham McKechnie
12/29/2005 2:47:02 PM

In my GPS program I've been testing with two different GPS units, a CF unit
and a BT unit. Therefore I'm using either COM6 or COM8 depending on the
unit. Either of these devices work perfectly as far as the GPS stuff is
concerned and have done so for quite along time.

I now want to write a routine to automatically discover a GPS device on
whatever port it may be attached. I can get the list of COM ports from the
registry, but I'm having real problems with my comm stuff when I attempt to
open a COM port that doesn't have a device attached to it.

It would appear from the debugger that WaitCommEvent is blocking when there
isn't any data to read, such as a COM port without a device. It sort of
makes sense as it is looking for some data which is never going to arrive.
Can anyone suggest how to make it time out or any other idea to get around
this problem.

I'm using a much modified (for CF), Comm class that was originally developed
by John Hind in a MSDN article a long time back. I've googled all over and
have read where the CommTimeOut ReadIntervalTimeOut being set to 0xfffffff
should eliminate this problem, but I'm not have any luck getting past this.

Using VS2005 and CF2.0

Graham

dotnet compact framework : WaitCommEvent