> >> that > >> they should wait, and clear that red sign when the comms is done? > > > > Because (a) that wouldn't prevent the CPU hogging, > > A modal dialog won't take any cpu cycles unless they sit there > and move it > around, click in the wrong places, etc...
I agree, but it would take a matter of seconds for the user to get irritated when they try and click a button that just happens to occur at the same time as a background comms check is going on, and it beeps at them or pops up a message box - same problem as simply disabling the interface, the comms calls are too frequent for that to be viable without making the UI suck. > With a modal dialog they don't have a choice. They can click in other > places of the app, but it doesn't do anything except "flash" at them and > "boing" to let them know they have to deal with the dialog first. Very true - but the above reason unfortunately negates that idea. > that the sync object was actually set. So you'd need a manual > sync object > and (depending on how you wanted to handle it) a counter that counted up > each thread that is awoke, when the counter is 5 you reset the > counter to 0 > and the sync object. I understand everything you're saying. In my case, by design there's only ever one thread setting the event (and it never wants to know when it becomes set), and one [other] thread checking it - but I may use manual anyway, in case in the future I have cause to have other threads. Future-proofing. > I do. Do a wait with your timeout as the value, then check the > return value > to see if it returned because it hit the timeout or because the > handle was > signaled. Interesting. Two people have said wait on the handle, a third said call GetOverlappedResult() and let that wait for it to finish. Does anyone want to change their mind? Are those two methods equally as valid, or might one have any kind of advantage? Note that I do not want this thread to hang caused by waiting for bytes that never come... waiting on the handle with a timeout sounds safer? -- Jason Teagle [EMAIL PROTECTED] _______________________________________________ msvc mailing list [email protected] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
