On Jul 11, 10:34 pm, "Tom Serface" <tom.nos...@camaswood.com> wrote:
Good point. I also forgot that Chris' dialog has a PeekAndPump()
function
that you can call for just this kind of case as well.
Thanks for the comments everyone. I think there's something I'm not
understanding clearly here.
As I understand it, your main application thread executes the
OnWhatever() handlers in your application's main window (mine is
actually based on CDialog), and also executes the GUI code which does
painting on the screen.
If the user (for example) clicks a "Process this file" button and I
then execute a lengthy piece of code to process a file then it is the
application thread that is doing that processing, so it does not get a
chance to do any processing of messages or painting to the screen
until that processing is finished. This results in the whole program
becoming unresponsive during the file processing.
But if during my file processing I regularly call a PeekMessage loop
then this gives a chance for the application thread to process any
queued messages and then return to my file processing.
But in my program the processing IS being performed in a separate
thread (actually it is a DirectShow filter graph that is running). My
program creates the CProgressWnd object and calls its GoModal()
function and then tells the filter graph to run (which runs in a new
thread).
After that I don't think my main application thread does anything
except execute a message handler which is triggered by the receipt of
progress messages posted from within the filter graph. This handler is
a method of my main window CDialog-derived class. When it is triggered
it calls a CProgressWnd method to update the progress bar, and also
calls a CProgressWnd method to query whether the user had pressed its
Cancel button - if the user has then it tidies up. So my progress
handler doesn't do anything else.
Surely then my main application thread is free to handle any windows
messages whenever they arrive because the heavy processing is being
done in another thread. And in fact the updating of the progress bar
is very responsive so the paint messages are getting executed without
any delay as far as I can see.
The only problem seems to be the windows message produced by the user
clicking the CProgressWnd's Cancel button which doesn't seem to end up
calling the CProgressWnd::OnCancel() handler unless I click it several
times rapidly and/or reduce the frequency of progress messages
produced by the other thread.
So firstly, is my understanding of the above correct?
And am I right to think that bacause the progress bar is painting
quickly and properly that the windows messages must already be being
processed properly by my main application thread, so I don't need a
PeekMessage loop? And if the messages are already being processed
correctly and quickly, then why isn't the cancel message always
getting through to CProgessWnd::OnCancel() ? Aren't the
CProgressWnd's message handlers being executed by my application main
thread aswell?
You are right, but maybe something is wrong with your PeekMessage loop. Are
To simplify, first start a 0.5 second timer. Then call CProgressWnd::Create
to put up the dialog modelessly. Then start your background thread that
starts the filter graph. When your primary thread receives messages from
the thread, call the CProgressWnd to update the progress. When your