Re: AfxBeginThread Question
On Tue, 6 Jun 2006 06:59:02 -0700, Saul775
<Saul775@discussions.microsoft.com> wrote:
I'm new to the environment of MFC, for I prefer Win32 whenever possible, but
I'm beginning to view the potential of MFC. I've a question about
AfxBeginThread.
I'm developing an application that uses two checkbox buttons. When you
click one checkbox the other checkbox becomes disabled, for the two events
associated with each button are mutually exclusive -- you can only do one at
a time.
The pseudocode is as follows...
If User Clicked CheckBoxXXX
OtherCheckBox.Disable();
MyClass.DoYourFunction(&CheckBoxXXX);
OtherCheckBox.Enable();
EndIf
Now MyClass.DoYourFunction has one argument, a CButton. All it does is the
following...
void MyClass::DoYourFunction(CButton *button)
{
while (button->GetCheck() == BST_CHECKED)
{
//Interface with COM/OLE
}
}
But this loop will never end as this function call is not multithreaded.
I've been working with old Win32 function calls such as _beginthread and
making the function call static and changing the arguments to void's, but for
some reason, WaitForSingleObject isn't working correctly, so I'm looking at
AfxBeginThread.
To use WFSO, you need _beginthreadex, but an MFC app should use
AfxBeginThread. To avoid the race condition and undefined behavior inherent
to MFC threads when waiting on the thread handle, which is similar to the
one arising from using _beginthread, see:
http://members.cox.net/doug_web/threads.htm
Is it possible to still call AfxBeginThread on my function call WITHOUT
deriving the class from CWinThread?
Yes. There are two versions of AfxBeginThread; you want the one that takes
an AFX_THREADPROC as its first argument.
That's a lot of overhead that is
unnecessary for my simple function call. I know I would need to change the
return type and arguments as follows...
UINT MyClass::DoYourFunction(LPVOID pVoid)
{
CButton *btn;
btn = (CButton*)pVoid;
...
}
You also need to make it static. But if you're proposing copying your loop
into this function, there are two big problems:
1. It is a busy-loop, which will use (the equivalent of) 100% of 1 CPU.
2. The GetCheck function boils down to SendMessage, which is tricky to use
across threads. Unless you really know what you're doing, only the thread
that created a window should send that window messages. You need to detect
button clicks in your main thread and communicate that information as
necessary with a worker thread, using, say, event objects.
--
Doug Harrison
Visual C++ MVP