Launch an app and get it's handle

[eblattner]

This has to be a stupid question, and I know there is an easy way to do it, but I don't know what it is! I am launching an app in code, and need to get the apps handle. I have tries CreateProcess, and ShellExecute, but the only way I have been able to get the handle is by using GetForgroundWindow right after when it launches. The problem with this is some apps have a splash screen that messes the whole thing up. Any help would be great, THANKS in advance!

 

[sodakotahusker]

Edbone,
Did you solve this yet??
I have the answer for you if not. Send me your email and I'll send you a module that has what you need (plus a bunch of stuff you don't need that I don't have time to remove).

 

[eblattner]

Thank you so much.. I have not figured out a fool proof way yet. My email is eddie_blattner@hotmail.com Thanks alot!

 

[jmarler]

Edbone,
Simply using the Shell command will return the process handle for the new application. Is this what you want? Of course, depending upon what you want to do, you may not have rights to that handle . . . you may need to generate another handle (based on the original) that will give you rights using the OpenProcess API (NOT the CreateProcess API).
Why don't you post what you intend to do with the handle, and I'll give you the best method to use.
- Jeff Marler B-)

 

[eblattner]

What I need to do is... Launch an app from code, and watch to see when it is closed (I use the timer control and FindWindow API). I am creating a shell that will launch any of 12 user-defined apps. It has a custom task bar that shows all running apps the user has launched. If the user closes one of these apps, I need to know so I can take it off the task bar. What I have been doing is watching the active window. When the user opens an app, and the active window changes to the newly launched one, I get the handle with GetForegroundWindow. This works fine as long as there is no splash screen. PC Anywhere, for instance, does not work this way. Any help would be great! Thanks

 

[jmarler]

hmmm . . . OK, using Shell and the OpenProcess API are still your best bets to get the application handle rather than using the FindWindow API, but actually, you may not even need the OpenProcess API unless you want to be able to close the other apps from your controlling applitication.
As for waiting for the other app to close, you could use the WaitForSingleObject API, but that would lock up your controlling appplication until the user closed the app they opened (unless VB could handle multiple threads, but it can't do that . . . yet). Of course you could write a C++ DLL that would use multithreading and simply signal you VB app when the other apps had closed . . . just a thought, but I think that this option would be the most responsive.
Using pure VB, I'd do this . . . Use the Shell command to lauch your applications. Keep the process ID that is returned from the Shell command. Then, using a timer control, periodically enumerate through the process list to see what processes are currently running (See code below). If you process handle is not in the enumerated process list, then the app has been closed.
Here is the code to get a list of just the running process IDs . . .

Private Declare Function EnumProcesses Lib "psapi.dll" (ByRef lpidProcess As Long, ByVal cb As Long, ByRef cbNeeded As Long) As Long

private Sub GetProcessHandles

    Dim lngProcessID()  As Long
    Dim lngCB As Long
    Dim lngCBNeeded As Long
    Dim lngRetCode As Long

    '** Get the current list of running Processes IDs
    '******************************************************************************

    lngCB = 8
    lngCBNeeded = 96
    Do While lngCB <= lngCBNeeded
        lngCB = lngCB * 2
        ReDim lngProcessIDs(lngCB / 4) As Long
        lngRetCode = EnumProcesses(lngProcessIDs(1), lngCB, lngCBNeeded)
        
        If lngRetCode = 0 Then
            MsgBox Err.LastDllError
            Exit Do
        End If
    Loop

    '******************************************************************************

End Sub

==================================================================================== - Jeff Marler B-)

 

[eblattner]

O.K. here is the problem The shell command will not let you specify a working dir or command line switches. This is why I was using ShellExecute. Also, when using shell, I am getting a negative number, not the handle to the app. It was a very good idea though, thanks!

 

[jmarler]

Shell is giving you a neg number? What OS are you working on? - Jeff Marler B-)

 

[eblattner]

Windows 98 First edition

 

[jmarler]

You may be getting the negative numbers if the OS/VB is converting unsigned numbers to signed. In this case the high bit being set would tell VB to display the number as negative. It may still be a valid handle . . . have you tried calling the OpenProcess API with the negative number returned by the Shell command? I do not have any Win9X boxes on my network, otherwise I'd test it myself. All of my dev work is on WinNT and WIN 2000.
Also, I have not used ShellExecute . . . could you please tell me what library you referenced to get that command since I am not seeing it in my VB6 Enterprise Version (SP4).
As far as specifying command line switches, you can do this with Shell. Still, managing the working directory could be an issue for you if you just use the shell command. Have you considered using the CreateProcess API? That returns the process handle (although it too may be negative for the afore mentioned reasons) and you can control the working directory and you can add command line switches. - Jeff Marler B-)

 

[eblattner]

I am using VB6 professional (sp5), but the ShellExecute is a Win32 API call. I think I will have to use the CreateProcess call, I just wanted to do it with smaller code. Thanks again for all the help!

 

[jmarler]

OK . . . my WIN32 API book did not list ShellExecute . . . feeling kind of cheated now . . . %-( - Jeff Marler B-)

 

[eblattner]

This is from the Windows API Viewer:

Public Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long

Check out MSDN article ID: Q114038 It's not real in depth, but gives you an idea on how it works.