platopus
asked on
Updating GDI/Multithreading
First, apologies for this not-so-clear description of my problem...
I'm trying to develop an SDI application (App A) using MFC, VC 5++ Enterprise version. App A monitors how long a totally separate calculation program (App B) has been running.
Several timers indicate elapsed time, the estimated time when App B should finish etc etc.
Whilst App A is running, as soon as I activate another window that covers part of App A's window, that region of App A's window is wiped out, even though in my code every five seconds all the timer displays are updated using UpdateWindow().
Activating App A's window has no effect. It's not that part of the window doesn't update - it's that the _whole_ window doesn't redraw, even though it becomes active.
As soon as App B finishes, App A's timers stop as intended...and at last App A's window updates and fills the screen again.
In other words, in order to see an up-to-date timer output, I cannot activate any other window whilst App A is running, because as soon as I do, App A doesn't redraw until it's finished timing.
My question - does anyone out there know of a simpler way than using multi-threading to update/redraw the whole window whilst the timing is going on ?
Alternatively (the best solution), could someone please let me know where I can find a real "bare bones" MFC template for multi-threading. I took a look at the MS multi-threading sample program and found it way too tricky to try and implement in my own code.
The GDI stays looking up-to-date whilst the main code handles the timers - is this really so difficult to implement or am I missing the obvious ?
I'm pretty new to Experts Exchange, so if you need more points, just say and I'll buy/try and save up some more!
Thanks a lot,
Sexton
I'm trying to develop an SDI application (App A) using MFC, VC 5++ Enterprise version. App A monitors how long a totally separate calculation program (App B) has been running.
Several timers indicate elapsed time, the estimated time when App B should finish etc etc.
Whilst App A is running, as soon as I activate another window that covers part of App A's window, that region of App A's window is wiped out, even though in my code every five seconds all the timer displays are updated using UpdateWindow().
Activating App A's window has no effect. It's not that part of the window doesn't update - it's that the _whole_ window doesn't redraw, even though it becomes active.
As soon as App B finishes, App A's timers stop as intended...and at last App A's window updates and fills the screen again.
In other words, in order to see an up-to-date timer output, I cannot activate any other window whilst App A is running, because as soon as I do, App A doesn't redraw until it's finished timing.
My question - does anyone out there know of a simpler way than using multi-threading to update/redraw the whole window whilst the timing is going on ?
Alternatively (the best solution), could someone please let me know where I can find a real "bare bones" MFC template for multi-threading. I took a look at the MS multi-threading sample program and found it way too tricky to try and implement in my own code.
The GDI stays looking up-to-date whilst the main code handles the timers - is this really so difficult to implement or am I missing the obvious ?
I'm pretty new to Experts Exchange, so if you need more points, just say and I'll buy/try and save up some more!
Thanks a lot,
Sexton
In order for your windows to be updated (repainted), you must be handling messages in a message loop.) Does your code execute a message loop?
How is Application A monitoring the time? What you should do is set up 1 (or a few timers) for it and it should execute a normal windows message loop. It should not be in a wait loop of some sort that does not process windows messages (at least not for a long time).
It might help if you were to post some of your relevant code. Give us an idea how application A is waiting, timing, handling messages, painting.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Oh, forgot to mention that "polling" your App B to see if it's don't is not the best way to do it. Windows provides other notification methods that don't require a timer or periodic checking. Probably the easiest is the WaitForSingleObject() API call. This will allow you to start App B as a thread, set an expiration time, and then just wait. If you want your windows to remain responsive (i.e. repaint itself), you need to start your App B as a thread, start another thread and call WaitForSingleObject() and have that thread send a message to your main thread when it completes using PostMessage(). In this case, you need no timers at all, Windows will handle the time-out period for you. It's also more efficient as your app doesn't waste time responding to timer messages.
jhance, how is your answer different than mine? I was waiting to see his code before I answered, in case he was doing it correctly and I had guessed at wrong problem.
ASKER
Hi Nietod,
This is my first C++ app of this scale, and I've only written apps using the MFC, so things are pretty primitive as far as message loops and suchlike !
Basically App A executes App B using ShellExecute( ).App A then performs the following loop (simplified a fair bit here to cut down on the length):
While (FoundAppBWindow ( ) == TRUE)
{
//code to increment all timer displays by one second.
//now wait for 1 second
ProcessSleep( (clock_t)1 * CLOCKS_PER_SEC );
//if 5 seconds have elapsed then UpdateWindow( ).
}
void ProcessSleep(clock_t wait)
{
clock_t goal;
goal = wait + clock( );
while( goal > clock( ) );
}
Thanks,
Sexton
This is my first C++ app of this scale, and I've only written apps using the MFC, so things are pretty primitive as far as message loops and suchlike !
Basically App A executes App B using ShellExecute( ).App A then performs the following loop (simplified a fair bit here to cut down on the length):
While (FoundAppBWindow ( ) == TRUE)
{
//code to increment all timer displays by one second.
//now wait for 1 second
ProcessSleep( (clock_t)1 * CLOCKS_PER_SEC );
//if 5 seconds have elapsed then UpdateWindow( ).
}
void ProcessSleep(clock_t wait)
{
clock_t goal;
goal = wait + clock( );
while( goal > clock( ) );
}
Thanks,
Sexton
Yes, your problem is that you are POLLING the clock instead of waiting for a notification message. USe a windows TIMER and respond to the WM_TIMER message to know when it's timed out. Your code never returns to Windows and even if you call UpdateWindow, the refresh doesn't get called, it just gets scheduled. You must return from your application before Windows will refresh your window.
nietod,
Sorry to step on you, but I thought you were beating around the question. This is a classic Windows programming mistake and having struggled through this myself, I was sure of the problem. As you can see from his code, that IS the problem.
If it's not, I'm sure platopus will let us know.
Sorry to step on you, but I thought you were beating around the question. This is a classic Windows programming mistake and having struggled through this myself, I was sure of the problem. As you can see from his code, that IS the problem.
If it's not, I'm sure platopus will let us know.
ASKER
Thanks for the comment jhance. Your analysis of the problem makes sense. I don't have any experience using these windows timers - if it's not too complex please could you provide me with a short code snippet showing how to use these ?
The reason I say this is that I keep coming across "new 32 bit" or "convenient" functions in VC++ only to find out that it takes 10 parameters and half a day to get them working in a "real life" program !
I'm using ShellExecute instead of CreateProcess to start App B because I'm "running" an associated file (the equivalent of double-clicking a .doc file in Explorer to open it in Word), not an executable. The executable doesn't accept command line parameters. Can you perform this associated run action using CreateProcess ?
The reason I say this is that I keep coming across "new 32 bit" or "convenient" functions in VC++ only to find out that it takes 10 parameters and half a day to get them working in a "real life" program !
I'm using ShellExecute instead of CreateProcess to start App B because I'm "running" an associated file (the equivalent of double-clicking a .doc file in Explorer to open it in Word), not an executable. The executable doesn't accept command line parameters. Can you perform this associated run action using CreateProcess ?
Agreed, That is why I said 1. He must be handling messages in a message loop and not waiting in a wait loop and 2. he needs to create a timer (or two) to get notifications.
The same points you made.
but go for it.
The same points you made.
but go for it.
That last comment was to jhance, not to platopus.
Just to keep you going platopus, why don't you look at the SetTimer() API. That is what jhance will show you how to use to create your timer notifications.
Just to keep you going platopus, why don't you look at the SetTimer() API. That is what jhance will show you how to use to create your timer notifications.
Here's how to setup a timer notfication using MFC:
1) Using the VC++ Class Wizard, add a WM_TIMER handler to your application. You should see an OnTimer function added to your class.
2) Edit the OnTimer function to do your housekeeping when it is called and then return.
3) In your code, where you want to start the timer, add a SetTimer(1, 1000, NULL); // The 1 is the timer ID and must be unique for each timer used in your application. If you only have 1, then use 1. The 1000 is the timer interval in mS. So this is a 1 second timer.
4) When you are done with the timer or you app is exiting, call KillTimer(1); Where the 1 is the ID of the timer used in SetTimer.
1) Using the VC++ Class Wizard, add a WM_TIMER handler to your application. You should see an OnTimer function added to your class.
2) Edit the OnTimer function to do your housekeeping when it is called and then return.
3) In your code, where you want to start the timer, add a SetTimer(1, 1000, NULL); // The 1 is the timer ID and must be unique for each timer used in your application. If you only have 1, then use 1. The 1000 is the timer interval in mS. So this is a 1 second timer.
4) When you are done with the timer or you app is exiting, call KillTimer(1); Where the 1 is the ID of the timer used in SetTimer.
ASKER
Thanks a lot to both of you for your comments. I got the SetTimer function working over the weekend.
The points go to jhance as he was the first to answer the problem correctly...sorry Nietod that you lost out through being cautious in diagnosing the problem...I'll be posting some real no-brainers in future so I'm sure you'll pick up some points on those :)
Sexton
The points go to jhance as he was the first to answer the problem correctly...sorry Nietod that you lost out through being cautious in diagnosing the problem...I'll be posting some real no-brainers in future so I'm sure you'll pick up some points on those :)
Sexton