I use the ShellExecute to execute notepad, and the return from that api is the HANDLE to the notepad, the handle is in a HMODULE, but after i try to use SendMessage, and give it the handle as the first argument, i get problems.
SendMessage wants a HWND but ShellExecute wants a HMODULE...
You might have to wait a few milliseconds or so while notepad starts up to get the handle, you can just use the Sleep() function.
ovidiucucu
February 2nd, 2009, 05:00 AM
The value returned by ShellExecute can only be used to see if the function succeeds or fails.
MSDN
Returns a value greater than 32 if successful, or an error value that is less than or equal to 32 otherwise. The following table lists the error values. The return value is cast as an HINSTANCE for backward compatibility with 16-bit Windows applications. It is not a true HINSTANCE, however. The only thing that can be done with the returned HINSTANCE is to cast it to an int and compare it with the value 32 or one of the error codes below[...]
The same think can be sayd about SHELLEXECUTEINFO::hInstApp retrieved by ShellExecuteEx. So, after launch an application using ShellExecute or ShellExecuteEx we lose the control on it.
FindWindow is not the better approach because it's possible to have more (Notepad) application main windows with the same class name and text (e.g. "Notepad" and "Untitled - Notepad").
Using Sleep it's also a not very good idea because we cannot know how long it takes to launch that application.
It's better to launch the application using CreateProcess. It takes an argument of type LPPROCESS_INFORMATION which in turn will give info about newly created process and its primary thread.
Further we can use these info to wait the until the application becomes active and get the main window handle.
For details and an example see this thread http://www.codeguru.com/forum/showthread.php?p=1801590#post1801590
ShadowRayz
February 2nd, 2009, 05:11 AM
Thank you all
BobS0327
February 2nd, 2009, 10:03 PM
I tried the CreateProcess method and the only way I could get it to work reliably was to put a delay in between the CreateProcess call and the window enumeration proc. Otherwise, the window enumeration proc will never identify the target window.
Thats because CreateProcess just immediately returns, so the window isn't fully created yet when you call FindWindow.
If you look at CreateProcess (http://msdn.microsoft.com/en-us/library/ms682425.aspx) on MSDN it stats in the 'Remarks' section that you can use WaitForIdleInput (http://msdn.microsoft.com/en-us/library/ms687022(VS.85).aspx) to wait until the process has completed loading.
Igor Vartanov
February 5th, 2009, 04:30 AM
If you look at CreateProcess (http://msdn.microsoft.com/en-us/library/ms682425.aspx) on MSDN it stats in the 'Remarks' section that you can use WaitForIdleInput (http://msdn.microsoft.com/en-us/library/ms687022(VS.85).aspx) to wait until the process has completed loading.Well, there are points to contemplate on:
1. The "launcher" application typically must be aware of regular "launchee" behavior.
2. The launcher has its own reasons for monitoring launchee window creation, and the reasons may vary from case to case.
3. Both applications may behave rather complex ways, so launcher must adapt itself as good as possible unless launchee was intentionally designed to communicate with launcher.
This gives us an idea that waiting for launchee idle input may be not acceptable for launcher (as long as the latter may want to communicate long before initialization finishes), and some other window-creation detection mechanism has to be used, like WH_CBT hook or something.
Well, the main idea of my speach is that such situation may have a number of solutions more than one, depending on particular requirements.
codeguru.com
Copyright Internet.com Inc., All Rights Reserved.