Callback functions

Hi all,

My windows application runs for quite a while, lots of processing to do.
The problem is while it is running the user interface doesn't respond, understandably so since it is a single threaded app. However, is there a way of displaying the progress of the application without resorting to dirty methods like sending user defined messages to the window from external modules?

Also, can I allow the user to break the operation at any time without having to create separate threads??

Would be much obliged for any help.
Thanks

Search this forum for idle processing.

You have to use a separate thread to execute all the logic while leaving the user thread free for user interface manipulation. you can use a callback mechanism but that too you have to do in a separate thread.


ritesh

Quote:

---

Originally Posted by riteshtandon

you can use a callback mechanism

---

Could you elaborete on "callback mechanism"?

In many cases using multithreading is completely unnecessary.
Allowing idle gui update is sufficient enough.

"callback mechanism" involves a function and calling that function whenever activities of interest happens with predefined arguments (similar to WndProc). This function can then delegate the action to an appropriate handler (mostly in a separate thread), but in current case even this would not work as the code is executing in the GUI thread, so a separate thread is needed to execute the complete code leavin the GUI thread for User interface

Quote:

---

Originally Posted by riteshtandon

but in current case even this would not work as the code is executing in the GUI thread, so a separate thread is needed to execute the complete code leavin the GUI thread for User interface

---

That is not correct.

Quote:

---

Originally Posted by me earlier

In many cases using multithreading is completely unnecessary.
Allowing idle gui update is sufficient enough.

---

And to support what I have said, I have written small dialog based program. Use one button to start never-ending while loop and see how it works without additional thread. It uses app designed ProcessIdle function that is called from within a loop. In this scenario, using scond button can stop loop.

Once you comment call to this function, recompile and run, application will cease to update UI and will freeze executing loop. Loop cannot be stopped.

Attachment folows.

Quote:

---

Originally Posted by Tamerocyte

However, is there a way of displaying the progress of the application without resorting to dirty methods like sending user defined messages to the window from external modules?

---

Well...I do not know since when is this considered a dirty method...nevertheless the following might be 'cleaner' for you... :cool:

• Idle Loop Processing.

In my sample I show similar approach, but code for that allows idle processing is in a function called from within a loop.

you are absolutely correct and your application is also perfect and solves the current problem.
But what you are using is the Windows messaging architecture and if you look more closely then you are actually using 2 threads provided implicitly by this architecture. One is the CDialog worker thread and other is the user interface thread. During every iteration u are checking the message queue of the user interface thread (the PeekMessage() function), during this check your "Button click" message is posted to the application queue which you retreive using the peekmessage function and you BtnStop function gets called which in turn stops the loop.

I have added a sleep() function in your existing start loop function to show the effect.

void CNoThreadButIdleDlg::OnBtnStartLoop()
{
m_bContinueLoop = TRUE;
while(m_bContinueLoop)
{
m_Progress.StepIt();
Sleep(2000);
theApp.ProcessIdle(); // comment this out to see difference
}

}

hmm... I haven't looked at the application, but a model dialog is not running in a
seperate thread from the application ui thread.

I am not sure about it but a window have at least two threads one is the worker thread and the other is the userinterface thread responsible for recieving the messages and dispatching it to the window.

ah... no there is no worker thread by default

Quote:

---

Originally Posted by JohnCz

Attachment folows.

---

are u sure it works?
but it doesn't response when i click stop button, maybe i should change ur code a bit?

I am not sure what i should call it but there is a main thread which contains all the code written by us.
Also there is a message queue(probably in User thread) which contains all the messages sent to it. These messages are then taken by the GetMessage or PeekMessage function for dispatching by DispatchMessage().
So in this case whenever you call the peekmessage function it gets the newly posted message (ButtonClick in our case) and acts appropriately.