On Fri, 07 Oct 2005 00:12:19 -0700, Dave said in
alt.radio.scanner:

It's my bug until I prove otherwise...unfortunately. Some
people say "don't use overlapped I/O when using serial
ports". Others (including Microsoft) say to use it. Who
knows. I'll get it fixed in time by the "puling out hair and
banging my fists on the table" method.

I've been doing serial I/O (in software) since before BASCOM, yet I've
never come across "overlapped I/O", as a term. Do you mean handling 2
ports simultaneously? What language? How are you doing the I/O?
(ocx? raw code?) (The program I'm currently working on does serial
and internet simultaneously, but that's not the same thing.)

Al Klein wrote:
I've been doing serial I/O (in software) since before BASCOM, yet I've
never come across "overlapped I/O", as a term. Do you mean handling 2
ports simultaneously? What language? How are you doing the I/O?
(ocx? raw code?) (The program I'm currently working on does serial
and internet simultaneously, but that's not the same thing.)

http://www.cpupedia.com/definition/overlapped+i_o.aspx
--
St. John

On Fri, 07 Oct 2005 17:30:01 GMT, "St. John Smythe"
wrote:

Al Klein wrote:
I've been doing serial I/O (in software) since before BASCOM, yet I've
never come across "overlapped I/O", as a term. Do you mean handling 2
ports simultaneously? What language? How are you doing the I/O?
(ocx? raw code?) (The program I'm currently working on does serial
and internet simultaneously, but that's not the same thing.)

http://www.cpupedia.com/definition/overlapped+i_o.aspx

Got it working on Win 2k, XP, Win/Me and Win98. Thanks to
some nice people who volunteered to help test it for me.

Regarding overlapped: If overlapped I/O is not used then
there is no way to cancel an I/O operation because the
thread is blocked. WIN32 has a CancelIO function in the same
API but CancelIO cannot cancel I/O on another thread, only
the same thread. That makes it a real pain in the ass. But
overlapping allows the programmer to break the I/O off and
clean up without having to be in the same thread, AFAIK.
That's why I had to use it in this case.

On Fri, 07 Oct 2005 18:35:54 -0700, Dave said in
alt.radio.scanner:

Regarding overlapped: If overlapped I/O is not used then
there is no way to cancel an I/O operation because the
thread is blocked. WIN32 has a CancelIO function in the same
API but CancelIO cannot cancel I/O on another thread, only
the same thread. That makes it a real pain in the ass. But
overlapping allows the programmer to break the I/O off and
clean up without having to be in the same thread, AFAIK.
That's why I had to use it in this case.

Seems like plain old polled I/O - you can cancel any time the I/O
routine is still in the wait loop. The last time I did that, though,
was under DOS 2.1, so I have no idea if it can still be done in a
Windows API.

On Sat, 08 Oct 2005 00:47:33 -0400, Al Klein
wrote:

Seems like plain old polled I/O - you can cancel any time the I/O
routine is still in the wait loop. The last time I did that, though,
was under DOS 2.1, so I have no idea if it can still be done in a
Windows API.

You can poll the serial port in Windows but it's not as
efficient as waiting for an event to happen while sleeping.
Normally, Windows wakes you up when the char arrives at the
serial port.

The way I set mine up is to issue a read of one byte while
in a loop. The loop is sleeping on the read command until
the char arrives. There is no CPU needed to poll since the
loop is asleep.

It's not a very easy to use API as I just found out but I
only have to write it and debug it once. Now that I have
something that works, I could send yo the source (in C++) if
you want to see what it looks like. It's a C++ class called
CComPort and it has 2 commands, ReadRxBuffer and
TransmitData. Both can be used simultaneously from different
threads without interfering with each other. It's quite nice
because I can use it for anything that needs to access the
serial ports without having to rewrite anything.

Well, it's late. I better try to get to sleep now. (4:40 am
Pacific time). I'm up late as usual.

On Sat, 08 Oct 2005 04:41:52 -0700, Dave said in
alt.radio.scanner:

It's not a very easy to use API as I just found out but I
only have to write it and debug it once. Now that I have
something that works, I could send yo the source (in C++) if
you want to see what it looks like. It's a C++ class called
CComPort and it has 2 commands, ReadRxBuffer and
TransmitData. Both can be used simultaneously from different
threads without interfering with each other. It's quite nice
because I can use it for anything that needs to access the
serial ports without having to rewrite anything.

I have a control that works pretty much the same way, except that the
Tx command can't be recalled - but I don't think I'll be needing that
capability.

I wouldn't mind having the code anyway, just in case. If you'd send
it to "Al at Webdingers dot com" (standard munging), please?

It works with the ICR7000. with Windows ME, XP, 2000 and 2003 server

On Mon, 10 Oct 2005 02:50:15 GMT, "Jacknopants"
wrote:

It works with the ICR7000. with Windows ME, XP, 2000 and 2003 server


Thanks for helping me test it. I'll add your radio to the
list of radios tested.

Best wishes!!