> Well, sorry to keep throwing up roadblocks to your suggestions, but
> (a) There are a lot of potential button handlers to add to!, and (b)
> same problem as disabling the interface / button - if you keep denying
> them every time they hit the button during a comms call, because of
> the sheer frequency of comms there could be, they'd have to hit the
> button at *exactly* the right time - and that's just not likely. The
> system would keep ignoring their clicks or beeping at them and I know
> I'd throw the PC out the window if it did that to me.
On the contrary, I would throw out the PC if it doesn't do what I *command*
it to do, but YMMV. :-)
> The ideal solution is that the button click is queued, so that it
> isn't processed when they click it but when the next free moment is
> after the comms have finished, which will hopefully be within 2
> seconds absolute maximum; this can't be done by simply posting a
> message since I have to pump messages to stop CPU hogging - one giant
> vicious circle. {:v) (There's no way to pull out all messages EXCEPT
> a certain user message, is there?)
There is! ::GetMessage( )! What else do you use to get your messages?! ;-)
> Surely that should be TRUE, to wait for the overlapped operation to
> complete? I used FALSE {:v)
>
> I think the reason I used FALSE was because I was worried that if the
> device failed, and no more bytes came back, then it would hang forever
> waiting...
> but would GetOverlappedResult() still obey the timeout specified by
> WaitCommEvent(), and thus not hang?
Please note that I never advised to set it to true. I just pointed out that
the fact that you have set it to false causes no waiting to occur. Indeed
if you set it to true, you might experience the problem you suspect (see my
other post on this.)
> I must admit I'm having a hard time picturing how this could be useful
> for reading a file, especially as the bytes are either there or not -
> it's not like you don't know whether more are coming. For streamed
> media, then yes, I can totally see the use. But maybe one day I'll
> have a project and realise how and why I can use it.
It is useful when reading large files, and manipulating them. For the fun
of it, try to write a program which copies a 4GB DVD image using a loop of
fread/fwrite's with a 1024-byte buffer, and compare it to a more advanced
version using overlapped I/O with large buffers (in megs) and see what
difference it makes! :-) And to be benefited by the merits of overlapped
I/O you should not necessarily be working with 4GB files, but AFAICT it has
little (if not no) use for streaming media...
-------------
Ehsan Akhgari
Farda Technology (http://www.farda-tech.com/)
List Owner: [email protected]
[ Email: [EMAIL PROTECTED] ]
[ WWW: http://www.beginthread.com/Ehsan ]
In the mountains the shortest way is from peak to peak, but for that route
you must have long legs. Aphorisms should be peaks, and those spoken to
should be tall and lofty.
-Thus Spoke Zarathustra, F. W. Nietzsche
_______________________________________________
msvc mailing list
[email protected]
See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for
subscription changes, and list archive.
