Using ShellExecute or CreateProcess caller lose its focus

[sdancer75]

Hi, No problem at all, I just gave all the code in the link. Anyway, I attach you the most important code from the sample app.

void CMainFrame::OnRunExternalApp() {

SHELLEXECUTEINFO	lpExecInfo;
PROCESS\_INFORMATION processInfo;
DWORD				dwExitCode;
HANDLE				hProcess = 0;
BOOL				bResult;
LPTSTR				strCmd;





strCmd = \_T("");

//bResult = StartupApplicationWithShell (\_T("LiveUpdate.exe"), (LPTSTR)strCmd,  GetSafeHwnd(), &hProcess);
bResult = StartupApplicationWithProcess (\_T("C:\\\\Windows\\\\notepad.exe"), (LPTSTR)strCmd,  &processInfo);

EnableWindow(FALSE);



if(bResult) { //(UINT)result > HINSTANCE\_ERROR)

	//ShowWindow( SW\_HIDE );
	//ShowWindow( SW\_SHOWNOACTIVATE );
	

    //WaitForSingleObject( hProcess, INFINITE );
	WaitForSingleObject(processInfo.hProcess, INFINITE);
	//WaitForMultipleObjects(1, &processInfo.hThread, TRUE, INFINITE );



	   
	//if (!GetExitCodeProcess(hProcess, &dwExitCode)) {
	//	   	AMLOGINFO(\_T("LiveUpdate is not terminated normally.")); 
	//}
	if (!GetExitCodeProcess(processInfo.hProcess, &dwExitCode)) {
		   	//failed
	}
	CloseHandle( processInfo.hProcess );
    CloseHandle( processInfo.hThread );
	//CloseHandle(hProcess);


} else {
	
	// failed
}

BringWindowToTop();
EnableWindow(TRUE);

//UpdateWindow();

//::SetWindowPos( GetSafeHwnd(), HWND\_TOP, 0, 0, 0, 0, SWP\_NOMOVE | SWP\_NOSIZE | SWP\_SHOWWINDOW );

}

sdancer75

[Victor Nijegorodov]

Maybe this will help you: windows forceforeground (bringWindowToTop) brings it to top but without being active (a forceForeGround that works with windows xp and windows 7) | Roger's woze[^]

[sdancer75]

I will give it a try but as you may already see, I am using the bringWindowToTop without success. Thanx

sdancer75

[Jochen Arndt]

My intention was to show you a solution that differs from your current implementation and pointing to the fact that you block the message loop. You must not call WaitForSingleObject from within your main thread to ensure that the window is repainted (e.g. when moving another window over the application window). That will solve the problem of paint corruption and might also solve your other problems. Overall I think I must shout: Don't use WaitForSingleObject from within your main GUI thread; especially with long wait times! I (like most others here) will not download a complete project and build it. Especially in this case where it must be tested with XP too.

[Victor Nijegorodov]

Yes, I see. But try it in the following order: EnableWindow SetForegroundWindow SetActiveWindow BringWindowToTop

[sdancer75]

Thanks for your time. Do you suggest to use WaitForMultipleObjects instead ?

sdancer75

[sdancer75]

Seems to work with one exception. I get a flicker since it instantly lose its focus and then regain it back....

sdancer75

[Jochen Arndt]

No. That is similar (it can just wait for more events). Don't use any blocking wait (or more general: any function that may block for long intervals) from within the main GUI thread. As already suggested you might use a worker thread.

[sdancer75]

The worker thread does not lock the main app as long as its active. I dont want this. I just want a modal like behaviour and not floating windows all around the desktop.

sdancer75

[sdancer75]

One last thing. The EnableWindow(xxxx) do the mess in my situation. If I dont use this function I have to process the paint messages from the child window. In this case I think that

WaitForMultipleObjects

will do the job in the XP case. Do you agree with this guess ? .... or better i will give it a try right now.

sdancer75

[Jochen Arndt]

You can disable your app window and/or show a modal dialog while the worker thread is active and re-enable when it finishes. So the message loop is not blocked and repainting is ensured while the app itself is blocked. What do you mean by floating windows? There is no additional window.

[sdancer75]

Quote:

You can disable your app window and/or show a modal dialog while the worker thread is active and re-enable when it finishes.

You mean a dummy dialog just to block to main app ?

Quote:

What do you mean by floating windows? There is no additional window.

I mean the two windows that will be active at the same time (main and child) and user will have the ability to work with the both of them.

sdancer75

[Jochen Arndt]

sdancer75 wrote:

You mean a dummy dialog just to block to main app ?

Yes. Or just disable the main window. The dialog can show something like "Please wait until the update is installed".

sdancer75 wrote:

I mean the two windows that will be active at the same time (main and child) and user will have the ability to work with the both of them.

When the app is blocked by disabling or a dialog it can't be moved by the user (the dialog may be moved). So when not using a dialog it is the same behaviour as with your current solution.

[Victor Nijegorodov]

No, WFMO is the same as WFSO (just waiting for more than one object; however I don't see any additional one in your problem description). The usual way is move waiting in a worker thread to not block the main UI thread.

[sdancer75]

Finally I used MsgWaitForMultipleObjects with message process loop. I avoid to use EnableWindow() function at all. It seems to work fine under Win7. I will take a copy to my work tommorow to test it under XP for paint corruption.

sdancer75