> I didn't mean just being polite and *asking* them not to do so, that won'r
> work for 99.999999% percent of the users! :-) I meant checking in your
> button click handler code if anything's going on in the
> background, and if so,
> show that red sign, and *abort* user's request.
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.
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?)
> I'd probably not bother to give a prefix to the whole thing. I'd probably
> call the variable "ov", but that wouldn't fix your problem, would it?!
Nope {;v)
"ov"... interesting.
> > but no for the second... can you explain why I should have manual
> > reset? I think this was one I didn't know what I should do, so I chose
> > automatic.
>
> Well, the big reason is that MSDN says so, and that is because maybe it's
> supposed to allow multiple threads to wait on the event. But I noticed in
> their sample code they're creating an auto-reset event, so it's yours to
> decipher this MSDN inconsistency, although I'd presonally create the event
> manual-reset, and call ResetEvent( ) myself when I get the notification.
OK, that certainly can't do any harm so I will try it.
> Now, like I suspected in my last email, there is *nothing* that
> causes a real
> "wait" in the loop, and that's the reason of CPU hogging. I
> guess now you see
> this.
Yes... I do now see that I've negated the usefulness of a wait call... doh!
> Yeah, definitely. You should call GetOverlappedResult( ) after your wait
> function returns successfully, and pass FALSE as its last argument.
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?
>
> BTW, in case it's not obvious, this is the overlapped I/O model
> in Windows.
> You can use it in any I/O (like file I/O, socket I/O, port I/O,
> etc.) and it
> always works like this. For example, to read a large file, you
> could issue 10
> I/O requests, and then call WaitForMultipleObjects( ) to automatically be
> alerted of which one finishes first, and then issue more requests
> if needed.
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.
--
Jason Teagle
[EMAIL PROTECTED]
_______________________________________________
msvc mailing list
[email protected]
See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for
subscription changes, and list archive.
