Re: EnableWindow() problem
Joseph M. Newcomer schreef:
It strikes me that this is the wrong solution. In particular, aHandles[0] will ALWAYS be
non-signaled, because it remains non-signaled as long as the process is running, and
therefore it is meaningless because it won't become signaled until the process terminates,
at which point you can't be looking for it.
That is true, but setting aHandles[0] has the side-effect of causing
WM_PAINT events if something partial exposes the main window. You will
probably argue that this is also not very elegant ;-)
The MsgWaitForMultipleObjects isn't the best approach; if you care about the other process
terminating, use something like my Asynchronous Process Notification scheme (see my MVP
Tips site). So you can eliminate MsgWaitForMultipleObjects here.
I will have a look.
I think this is an overly complicated approach to a trivial problem: is the other process
running?
EnableWindow does not set focus. SetForegroundWIndow or BringWindowToTop will do it, and
SetFocus, of course.
EnableWindow CERTAINLY will not restore the window if it is minimized; you should use
ShowWindow(SW_RESTORE) to accomplish this.
Enabling is just enabling, and carries no more semantics than that.
Frankly, I would not disable the window at all; I would simply disable parts of the GUI
such as (if a CFormView) the controls. I might disable the close button. But I'd leave
anything I needed active. You have committed the classic design error of thinking
sequentially in an asynchronous world, and that leads to all kinds of complexity. Instead
of disabling the window, disable what the window can do! Now you can drag it around,
minimize it, maximize it, show information about the child process, etc., etc.,
Instead of doing a targeted disablement of only the relevant user input features, you have
chosen to disable the entire window. That is not really a good solution to the problem.
If the user right-clicks on the icon, there is an expectation that *something* should
happen; if the window is disabled, *nothing* will happen. This is the brute-force
sledgehammer approach to solving the problem, whereas what you should consider is a
"surgical strike" on just the UI components that matter.
Well, I see you reasoning. My original code just did a
ShowWindow(SW_HIDE) as the user could really do nothing while the other
application was running. But this caused panic as "the window was gone".
joe
On Tue, 19 Jun 2007 11:33:35 +0200, Theo Landman <tlandman_NO_SPAM@justcroft_NO_SPAM.com>
wrote:
Hello,
I have trouble with AfxGetMainWnd()->EnableWindow() at least on Windows
XP. Not tested this . My main application needs to run another GUI
program and while this program run should not be accessible for user
input. In order to do this I call AfxGetMainWnd()->EnableWindow(FALSE);
Start the GUI program Then use a bit of code to wait for the GUI to
finish. See snippet below:
HANDLE aHandles[2];
aHandles[0] = GetCurrentProcess();
aHandles[1] = hGUI;
do
{
DWORD dwResult = ::MsgWaitForMultipleObjects(2, aHandles,
FALSE, INFINITE, QS_ALLEVENTS);
if ( !prcGUI.IsRunning() )
break;
} while ( AfxGetThread()->PumpMessage() );
However, when the GUI program stops my main application won't get the
focus automatically again after I call
AfxGetMainWnd()->EnableWindow(TRUE); The application behaves as being
minimized and I have to explicitly click on the program icon in the
desktop bar to bring it back up.
I tried different combinations of SetActiveWindow(),
SetForegroundWindow(), BringWindowToTop() and SetFocus() but nothing
happens.
If I don't use EnableWindow() this problem does not occur.
So in short how to force my application back to the foreground?
Any help appreciated,
Theo
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm