Archived

This topic is now archived and is closed to further replies.

How to show that application is busy and not dead...

This topic is 5501 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, My windows application performs from time to time long computations (from several seconds to several minutes) and I was wondering what the best way is to show that the application is busy and didn''t crash. My application is single threaded and I have a single window in which I render a 3D scene with OpenGL. How is this usually handled? I can think of 2 ways: 1. A second thread displays an auxiliary window with a message and blinking cursor. Problem is that if the application really crashed, the second thread will still pretend the application is busy... 2. In every time intensive routine, I call from time to time a function which will decide if it is time to refresh a message and my OpenGL window (no re-rendering, just swapping between buffers). Problem appear with modal dialogs (like the one to load files): the OpenGL window can''t get refreshed if we move other applications on top... How do you do it?? Thanks

Share this post


Link to post
Share on other sites
quote:
Original post by Floating
My windows application performs from time to time long computations (from several seconds to several minutes) and I was wondering what the best way is to show that the application is busy and didn''t crash.

You shouldn''t tie up the UI while doing lengthy processing!
quote:

My application is single threaded and I have a single window in which I render a 3D scene with OpenGL.

That''s your problem. You should spawn a thread to do any lengthy processing tasks so that the UI thread isn''t tied up. If you need to talk between the UI and thread, then there needs to be a way of intercommunicating and a set of messages representing the protocol. For Windows, you may be able to use the message pump for intercommunication. The other option is to use shared memory regions with appropriate concurrency protection.

Share this post


Link to post
Share on other sites
The idea of the worker thread to do the computation is good if you can easily separate the objects computed on from the objects beeing displayed and animated... But that seems sometimes very complex to achieve! I would need to put locks a bit everywhere in my objects and I feel safer using a single thread for object access/manipulation. I''ll have to think a bit more about it.

Anyway, thanks for the replies

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
if you really want/need to use a single thread, then you could code up a little function that loops until no more Windows msgs are found in your msg queue. something like this (untested):

UINT Window::CheckMsgs()
{
MSG msg;

if( PeekMessage(&msg, NULL, 0, 0, PM_REMOVE) ) {
TranslateMessage(&msg);
DispatchMessage (&msg);
}

return msg.message;
}

then just "periodically" call the function within your number cruncher processing. you would still need to do some cleanup/synch-up but that might be handled via a global "want-to-quit" bool that''s set in your msgproc and tested after every call.

Share this post


Link to post
Share on other sites
If I''m using MFC, I create a CWaitCursor object that turns the cursor into the "waiting" cursor. Dunno how to do it in win32, but it should be easy to figure out.

Share this post


Link to post
Share on other sites
quote:
Original post by Floating
The idea of the worker thread to do the computation is good if you can easily separate the objects computed on from the objects beeing displayed and animated

You should be doing that anyway.
quote:

I would need to put locks a bit everywhere in my objects and I feel safer using a single thread for object access/manipulation.

You don''t need concurrency protection *everywhere*, you need it where there are shared resources. If the subtasks communicate via the Windows message pump, you might not actually have any shared resources.
quote:

If I''m using MFC, I create a CWaitCursor object that turns the cursor into the "waiting" cursor.

That''s OK for delays of up to about 5 seconds. Above that, you should be showing a visual indicator that the application is still doing something - usually a progress bar. It is also good to give the user the option of cancelling the action whilst in progress.

Share this post


Link to post
Share on other sites