Problem getting window handle for control panel applet.

[therms]

$appletPID = Run("control.exe /name Microsoft.AudioDevicesAndSoundThemes")

The pid of the window that is opened (obtained by using WinList and looking for the window with the title "Sound") doesn't match $appletPID.

This is a problem because I want to be able to have the handle for that window no matter which language the user is running Windows with. Other languages won't have a window title of "Sound".

I assume that control.exe is spawning another process which actually opens the "Sound" window. I just can't figure out how to make sure I'm getting the right window when there is no guarantee what language the user is running...

Anyone have any suggestions on how to get the Sound applet window handle when I don't know the window title in advance, or how to make sure I get the "correct" PID when running the above code?

Currently I'm using the windows class...just looking for a more general solution.

Edited January 7, 2012 by therms

[Beege]

The macro @OSLang will return the code for what language the OS is currently using. Get the language, then the translation of "sound" to that language. This is just an idea, never tested..

[therms]

The macro @OSLang will return the code for what language the OS is currently using. Get the language, then the translation of "sound" to that language. This is just an idea, never tested..

Yeah, I thought of that. I just wanted to avoid having to pre-determine what Microsoft called the Sound applet in all the different possible languages.

Thanks for the idea, though!

[JohnOne]

Maybe something like this, but I'm sure there are other ways to get a handle from PID

Local $hSoundWindow
$hCurrentActive = Wingethandle("[ACTIVE]")
Consolewrite($hCurrentActive & @crlf)
$appletPID = Run("control.exe /name Microsoft.AudioDevicesAndSoundThemes")
Do
$hSoundWindow = Wingethandle("[ACTIVE]")
Until $hSoundWindow <> $hCurrentActive
Consolewrite($hSoundWindow & @crlf)

[therms]

Thanks for the suggestion, JohnOne. I was worried about whether that would be robust enough...imagine a scenario where another window became active before the Sound applet appeared.

I ended up doing something like this:

I know the Sound applet window class, so get all windows with that class (there will probably be several...for example Task Manager shares the same window class). Then iterate over each window first looking for a tab control and if it has a tab control moving it to the first tab and looking for the list view containing the devices . I can do two checks to see if this listview is a sound device list view...first every item should have three sub items, and I also know the sound device name because of previous user interaction with my application.

Repeat until those tests pass. On each pass through those tests I make sure to put the active tab back to what it was when I moved to the first tab to check for a list view so I don't mess with the user's windows.

[JohnOne]

I thought you might have searched the forum after I hinted "get a handle from PID"

Anyway here is I just found by guinness

[therms]

I thought you might have searched the forum after I hinted "get a handle from PID"

Anyway here is I just found by guinness

But that's the whole problem. As I mentioned in the original post, I don't know what the PID is. If I knew the PID it's trivially easy to get the handle. Run() doesn't return the correct PID.

Edited January 10, 2012 by therms

[JohnOne]

I see, I never read that correctly.

Anyway, the process that is spawned is rundll32.exe but for me, the PID is still not the same.

I imagine the next step would be to somehow enumerate all its child processes.

Edited January 11, 2012 by JohnOne