An multithread question.
cwy...@cis.nctu.edu.tw
I've now encountered a hard problem.
As we know, in a dialog-based program, when we press a
button, the windows wait for the corresponding procedures
to be executed. During executing those procedures, the other
windows message won't be taken care.
I've ever used a library, it provides two functions.
One is Go(), and the other is Stop().
I created two corresponding buttons ButtonGO, and ButtonStop
to do Go() and Stop().
I don't have to use AfxCreateThread in OnBottonGO. When I press
ButtonGo, the ButtonStop button is still pressable!
When I press ButtonStop, the OnButtonGo() function shall return.
How this can be done?
Any suggestion will be appreciated.
David Wilkinson
[snip]
> I've ever used a library, it provides two functions.
> One is Go(), and the other is Stop().
> I created two corresponding buttons ButtonGO, and ButtonStop
> to do Go() and Stop().
>
[snip]
cwyang:
What does this mean? You have such a library, or you want to write one?
What is the problem exactly?
David Wilkinson
cwy...@cis.nctu.edu.tw
I mean I have ever have one library doing such similar stuff.
Now I have to write my own one which will be in the same fashion.
2 buttons, when one button is pressed and proccessing, the other
should be press-able. And the button handling fuction cannot
create any thread.
Sincerely
David Wilkinson
> Sorry for my roughness.
>
> I mean I have ever have one library doing such similar stuff.
>
> Now I have to write my own one which will be in the same fashion.
>
> 2 buttons, when one button is pressed and proccessing, the other
> should be press-able. And the button handling fuction cannot
> create any thread.
>
cwyang:
You mean: you once had a library doing similar stuff.
Something like this:
The Go() function should have an argument which is a pointer to the
thread function.
The Go() function should call AfxBeginThread().
The Stop() function should set some kind of flag
The thread function should be designed so that it checks the value of
the flag from time to time.
ButtonGo handler should call Go(). Go() returns immediately after
launching the thread, so the handler exits, freeing up the message loop
for the ButtonStop handler.
David Wilkinson
Michael K. O'Neill
<cwy...@cis.nctu.edu.tw> wrote in message
news:1156768337.9...@h48g2000cwc.googlegroups.com...
This can be done if the button handler (or the Go() function) pumps messages
while it is executing. Code like this:
void Go()
{
while (GoFunctionIsNotYetDone)
{
// do part of a lengthy procedure
// ..
// every once in a while, pump messages
MSG msg;
while( ::PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) != 0 )
{
::TranslateMessage( &msg );
::DispatchMessage( &msg );
}
}
}
This code will periodically pump messages, including mouse messages and
notifications like BN_CLICKED, and thus your buttons will remain press-able.
Code like this originated with early Windows OS's like Win 3.1, in which
applications could not be multi-threaded. The classic example of this code
is found in Petzold's example for the "Cancel Print" dialogs that were
displayed while processing a document for printing (which was a lengthy
process).
Use of code like this now is not generally recommended, since current
Windows OS's are all pre-emptively multi-threaded. Unless you have a real
need not to create a thread, it's generally recommended to create the thread
instead of using "pump messages" code like that above.
Mike
Joseph M. Newcomer
The key here is to make sure the Stop button is disabled if there is no thread, and the Go
button is disabled if there is a thread. I do this by using a single method that handles
all control logic and make sure it is called when there is a state change that might
affect the control state.
I don't understand what you mean when you say you "don't have to use AfxCreateThread". If
you want to create a thread, you have to create it somewhere. You may create it when the
thread is created and destroy the thread when it is finished. An alternative model is you
create the thread at program startup, and the Go button sends it information to process,
so you disable Go and enable Stop if the thread is "working" and reverse this state when
it is stopped. Asynchronous notification by way of posted messages is a common means of
handling this.
See my essays on worker threads and UI threads on my MVP Tips site.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer
performance badly and adds gratuitous complexity to the problem of simulating concurrency.
It should be thought of as a very-special-case API and this is not one of the very special
cases. Use threads.
joe