> Suggestion (feel free to ignore, since you know more about the context of
> your application):
> How about not disabling the buttons, and pumping the messages, and just
> alerting the user with a red sign (not a modal message box of course) that
> they should wait, and clear that red sign when the comms is done?
Because (a) that wouldn't prevent the CPU hogging, and (b) because users
never obey what they're told and will always try and click something anyway
{:v) I would feel that this makes the app non-robust since it relies on the
user playing nice, and if they don't, the app provides incorrect information
since it gets its comms mixed up (been there, done that in early
iterations - the result was not good).
But I appreciate the suggestion.
> I wonder what the "s" prefixes mean to OVERLAPPEDs? :-)
Structure {:v) Cue the arguments about what the prefix should be {;v)
> > if (!::WaitCommEvent(rsThreadData.hPortHandle, &dwEvent,
> >
> > &rsNotifyOverlapData) )
>
> (Just checking...) Is rsThreadData.hPortHandle opened with
> FILE_FLAG_OVERLAPPED? Is the hEvent member of the OVERLAPPED object
> properly created as a manual-reset event?
Yes for the first...
m_hPortHandle = ::CreateFile(lpszPortName, GENERIC_READ|GENERIC_WRITE,
0, NULL, OPEN_EXISTING,
FILE_FLAG_OVERLAPPED, NULL);
(that handle gets set into the rsThreadData member accordingly)
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.
> You're passing FALSE as the last parameter to
> GetOverlappedResult( ). This
> causes it to return immediately at any case, which might lead to another
> roll of the loop, according to what you've tried to hide in the
> "etc." part!
> Now that I've caught you red-handed, I guess you need to post the rest of
> this function as well. ;-)
// Wait for completion of WaitCommEvent().
while (!rsThreadData.bTerminate && !bDone)
{
bDone = ::GetOverlappedResult(rsThreadData.hPortHandle,
&rsNotifyOverlapData,
&dwDummy,
FALSE);
dwError = ::GetLastError();
if (!bDone && dwError != ERROR_IO_INCOMPLETE)
bDone = TRUE ; // Real error.
}
Thoughts? Told you this was my first foray into the seedy world of handles,
events and threads {;v)
> Which makes me think why they've prefixed the function's name with "Wait"!
> Maybe it's just been the Hungarian Notation?! ;-)
Good point!
> > Note that asynchronous comms is useless as I need to wait until either
> > I get a valid response to what's sent, or a timeout occurs. It's a
> > master / slave system (Modbus).
>
> OK, I won't pretend I know anything about Modbus. Did any of the above
> help?
I think it may, if you have any more thoughts about that inner loop in
WaitForRX() - Daniel suggested I should simply wait for the handle in the
OVERLAPPED structure to become signalled, I guess you would concur?
--
Jason Teagle
[EMAIL PROTECTED]
_______________________________________________
msvc mailing list
[email protected]
See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for
subscription changes, and list archive.
