But the Window Handle is a Main or Mainframe Window
I did a FindWindow api call
To get the handle As the parent is a C console app and it did work once before I created the modless dialog box in the child process
No, you just need to find its handle by one of the enumerate functions, or get the child to pass it back in some way. A handle is just a pointer used to identify a Window so you can send messages to it. To be honest, I am not exactly clear about what you are trying to do beyond the basic SendMessage function.
I want to call an external application (created by me) using ShellExecute or CreateProcess. It is just an update application for the main app. The problem is, what ever I tried I failed to get window focus back to my main app when the process (update app) is terminated. I created a simple MFC/SDI app that calls window's notepad under "C:\windows\notepad.exe" which suffers from the same problem, just to show you what I mean. I need the parent window -which is the main app- to be disabled (like a modal dialog box behaviour) until the new app -update application- will finish its job.
PS:If I do not disable the main window with EnableWindow(FALSE) I have paint corruption with windows XP and back when I move the update application.
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.
When the external update process should also update the executable of your main application, that must be terminated before the new exe file can be copyied. So there is no need to get the focus back.
A typical sequence for such a process:
Ask the user if the update should be installed
Perform closing tasks that are time consuming or require user interaction like closing open documents
Start the update process
Terminate your application
The update process should check if there is a running instance of your application (after a short wait time) and terminate with an error if so
The update process might restart your application
In another post you mentioned that you are using WaitForSingleObject to wait for the update process to be terminated. If you call that from within your main thread, your application's message loop is blocked so that paint events are not processed.
If you don't want to update the executable itself and must wait for the external process to be finished start the process from within a worker thread where you can call WaitForSingleObject without blocking the message loop. Use a global state variable indicating that the update is executing to disallow specific tasks of your application or just show a modal dialog that is closed automatically when the update has finished.
Last Visit: 2-Dec-20 0:50 Last Update: 2-Dec-20 0:50