From Newsgroup: alt.windows7.general

Paul,

By the way :

Returned Answer

...

if (ShellExecuteEx(&sei)) {
DWORD pid = GetProcessId(sei.hProcess);
// Now use this PID to find the window
}
```

2. Enumerate all top-level windows and match the PID:

'''cpp
HWND targetHwnd = nullptr;

EnumWindows([](HWND hwnd, LPARAM lParam) -> BOOL {
DWORD windowPid;
GetWindowThreadProcessId(hwnd, &windowPid);

if (windowPid == (DWORD)lParam) {
// Optional: Check if it's an Explorer window
wchar_t className[256];
GetClassName(hwnd, className,
sizeof(className)/sizeof(wchar_t));
if (wcscmp(className, L"CabinetWClass") == 0 ||
wcscmp(className, L"ExplorerWClass") == 0) {
targetHwnd = hwnd;
return FALSE; // Stop enumeration
}
}
return TRUE;
}, (LPARAM)pid);
```

When I checked my (now year-old) experimenting/testing code does exactly
that - but even when I sleep for a second before EnumWindows I do not get a match. A slew of windows, but no match.

Proc 0000060C
Pid 00000ED4
hWnd 00040264 Pid:000005BC 'CabinetWClass'
hWnd 000801AE Pid:000005BC 'ExploreWClass'
hWnd 0010017C Pid:000005BC 'ExploreWClass'

(just showing the explorer-class results).

Regards,
Rudy Wieser



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Another thing :

2. Enumerate all top-level windows and match the PID:

'''cpp
HWND targetHwnd = nullptr;

EnumWindows([](HWND hwnd, LPARAM lParam) -> BOOL {
DWORD windowPid;
GetWindowThreadProcessId(hwnd, &windowPid);

if (windowPid == (DWORD)lParam) {
// Optional: Check if it's an Explorer window
wchar_t className[256];
GetClassName(hwnd, className,
sizeof(className)/sizeof(wchar_t));
if (wcscmp(className, L"CabinetWClass") == 0 ||
wcscmp(className, L"ExplorerWClass") == 0) {
targetHwnd = hwnd;
return FALSE; // Stop enumeration
}
}
return TRUE;
}, (LPARAM)pid);

The code doesn't consider the, very likely, possibility of another file-explorer window already being open.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2025-10-08 03:31, JJ wrote:

On Tue, 7 Oct 2025 10:12:54 +0200, R.Wieser wrote:

Hello all,

I'm in a bit of picle : I'm using user32.dll's ShellExecute to open another >> file explorer window, which I than want to move around.

The problem is that ShellExecute doesn't seem to return a handle to the
just-created explorer window (if someone knows how to get it from
ShellExecute I would like to know!).

So, I'm using FindWindowEx to find the file-explorer window. Alas, it
doesn't find the window if its created mimimized.

Question: how do I find a (or rather: the last-created) file-explorer
window, minimized or not ?

I've just been googeling, but am not getting any results (pertaining to the >> problem. Lots of others though. :-( )

Regards,
Rudy Wieser

Use `Shell.Application` COM object to enumerate all explorer windows. Minimized or not, and hidden or not. Do like what it does, if COM usage is not applicable/acceptable.

Previous posts already included how to do the enumeration without COM
overhead . The problem is that launching (directly or indirectly) explorer.exe may randomly cause the launched explorer process to pass
the request to any of the already running explorer.exe processes, in
which case the problem is to determine /which one/ of the explorer
windows owned by the various explorer.exe processes pertains to the
request just made to ShellExecuteEx().


Enjoy

Jakob
--
Jakob Bohm, MSc.Eng., I speak only for myself, not my company
This public discussion message is non-binding and may contain errors
All trademarks and other things belong to their owners, if any.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Jakob, others,

The problem is that launching (directly or indirectly) explorer.exe may randomly cause the launched explorer process to pass the request to any of the already running explorer.exe processes, in which case the problem is
to determine /which one/ of the explorer windows owned by the various explorer.exe processes pertains to the request just made to ShellExecuteEx().

As mentioned, I *never* get a process handle back which has an explorer
window (might be because I'm using WinXP), so I just scan all the windows.
It doesn't make a difference (just takes a bit more time).

Also, ShellExecute(Ex) may return well before the actual window has been created (regardles of the SEE_MASK_WAITFORINPUTIDLE flag application).

One other problem I found is that when I get a CabinetWClass window the next attempt to open the same folder doesn't create a new window, but just (restores and) focusses the old one.

And something I overlooked : You cannot tell a minimized (or maximized)
window to move around.

Bottom line: I have to create the new explorer window normally, move it
around and only than, if wanted, minimize it.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 13.10.2025 07:32, R.Wieser wrote:

Jakob, others,

The problem is that launching (directly or indirectly) explorer.exe may
randomly cause the launched explorer process to pass the request to any of >> the already running explorer.exe processes, in which case the problem is
to determine /which one/ of the explorer windows owned by the various
explorer.exe processes pertains to the request just made to
ShellExecuteEx().

As mentioned, I *never* get a process handle back which has an explorer window (might be because I'm using WinXP), so I just scan all the windows. It doesn't make a difference (just takes a bit more time).

Also, ShellExecute(Ex) may return well before the actual window has been created (regardles of the SEE_MASK_WAITFORINPUTIDLE flag application).

One other problem I found is that when I get a CabinetWClass window the next attempt to open the same folder doesn't create a new window, but just (restores and) focusses the old one.

And something I overlooked : You cannot tell a minimized (or maximized) window to move around.

Bottom line: I have to create the new explorer window normally, move it around and only than, if wanted, minimize it.

hi,

have you maybe tried FindWindow?
If you know the exact title bar text it should work.
(if you don't open the same folder window twice...)

ciao..

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Schugo,

have you maybe tried FindWindow?

Yep. I used that in my first version of my program (from before I posted my question).

The thing is that that doesn't quite work when you try to open a
CabinetWClass window using the same folder.

If you know the exact title bar text it should work.

I thought of that too, but I dislike the idea of having the commandline
parsed twice (once by my program, a second time by explorer.exe).

(if you don't open the same folder window twice...)

Well, the thing is that I would like my program to work regardless of the commandline thats provided (including "/e", "/n" or neither). I'm looking
at it as a challenge. :-)

Thanks for the suggestion.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2