C++ Launching Application / Mouse Event Trouble

[Escher]

Here's the setup: App #1 has a push button that launches app #2, and it waits for app #2 to exit before becoming active again using this code:

if(CreateProcess(appName, cmdLine, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi))
{
     WaitForSingleObject(pi.hProcess, INFINITE);
     CloseHandle(pi.hThread);
     CloseHandle(pi.hProcess);
}

Here's the problem: If the user clicks on the button multiple times (even after app #2 has launched), even though the application is non-responsive, it appears to hold onto the mouse events and will process them once app #2 has exited. This of course results in app #2 being relaunched again and again depending on how many times you "clicked" the button.

How do I keep app #1 from processing these messages?

 

[Nanan]

Do you have the ability to pass var's from app1 to app2? If so then a simple boolean check could be used to see if app2 is launched, if so then don't try to launch again till the value has been returned by app2.

 

[Tytalus]

Here's the setup: App #1 has a push button that launches app #2, and it waits for app #2 to exit before becoming active again using this code:

if(CreateProcess(appName, cmdLine, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi))
{
     WaitForSingleObject(pi.hProcess, INFINITE);
     CloseHandle(pi.hThread);
     CloseHandle(pi.hProcess);
}

Here's the problem: If the user clicks on the button multiple times (even after app #2 has launched), even though the application is non-responsive, it appears to hold onto the mouse events and will process them once app #2 has exited. This of course results in app #2 being relaunched again and again depending on how many times you "clicked" the button.

How do I keep app #1 from processing these messages?

Well, as a simple recommendation.... couldn't you un-bind the event handling for the button while the second app is launched, and then when that app returns reassociate with the click event on that button? I know it's the cheezy, cheap way out that requires little or no thought.... but it would work.

EDIT: One additional idea if this isn't exactly what you need (you didn't provide much code, compiler info, O/S, etc.) would be to create a global Mutex in App2 and check it in App1. If the global Mutex exists (essentially use it as a flag indicating "App2 is open") then don't process the code in the click event handling for the button in App1.

 

[tesfaye]

Disclaimer, I code mostly in C#.

If it were me I would disable the button and then handle the process close event (or whatever the C++ equivilant is). The handler for the process close event would enable the button. I personally hate unresponsive windows.

 

[mikeblas]

There's no need for interprocess communication.

As tesfaye suggests, you can disable the button after launching. Then, occasionally check the process handle. When it's signaled, you can close the resources and re-enable the button.

 

[Nanan]

I just suggested that because it was very similar to a home work problem I had back in my c++ class in high school.

 

[Escher]

The problem is that the app seems to queue up the message events on it's own and only processes them after the 2nd application terminates, so even when I disable the button and re-enable after the launched app terminates, the button event is processed.

I also tried intercepting using PreTranslateMessage, but again, the additional mouse clicks on the button are only processed there after the other app terminates and control is returned to the calling app.

Is there not a way to tell an app to stop processing mouse events and/or flush the message pump for the dialog so the mouse event is tossed out?

 

[mikeblas]

Sorry if I wasn't clear. The suggestion was to disable and re-enable the button, but not wait for completion in the message handler for the on click on the button. The reason your application stops processing messages is that you tell it to by blocking on WaitForSingleObject().

 

[Escher]

No, I think I understood you Mike, but it doesn't matter if I disable the button or not. Somewhere high up the mouse click is being cached off and then processed only after the first mouse event handler is over and done with. When that first event handler is done, the mouse click is interpreted as a click on the button, and if that button is enabled, it will fire the event handler. I have to assume your suggestion includes re-enabling that button before the first event handler terminates, else, when would I have an opportunity to do it?

Found a solution. In the button event handler I call BlockInput(TRUE), after CreateProcess I do a WaitForInputIdle on the newly created process and when it's done I call BlockInput(FALSE). This appears to fix all the issues I had, so unless someone can think of a better way, I'll consider this thread closed.

Thanks for the suggestions guys!