During usage of the Jumptofolder tool some questions came up.
To support NotNull I will ask two questions (each in a separate thread):
Is it somehow possible to interact still with an explorer window even when explorer replacement is active?
Or to ask it in another way: Is it somehow possible to use a ShellExecute() call and tell Opus not to "steal" this call from explorer?
First answer from Leo in the tool thread was:
yes, either run explorer.exe explicitly or use the “open” verb explicitly in the ShellExecute call and Explorer will open.
The problem is not to open explorer, but e.g. to tell explorer to select a specific file.
Background of the question: NotNull wants to improve the tool. If a file is selected in the Everything search window the file shall be selected.
Issue with Opus installed and active explorer replacement:
Directory Opus has an Explorer Replacement mode where most Explorer calls to Explrer are being intercepted through a shellhook.
This means that I can't tell Explorer to select a specific file without Opus interfering and either passing the call to Opus itself or causing a crash.
To bypass the shellhook will need a lot of ugly workarounds (as far as I can tell at this moment in time).
First of all: thank you @Mosed for helping out here.
If it weren't for you, I would have dropped support for Opus in JumpToFolder.
The case here is about "remote controlling" a running File Explorer, not about creating a new Explorer process.
JumpToFolder enables you to type in a few characters of the file/folder you want to browse to, select the right one from a list of matching folders and changes the active folder in File Explorer to that folder.
Other file managers - like Directory Opus - and Open/Save dialogs are supported too.
As File Explorer supports COM, that is the usual way to interact with it.
With that one can:
get a list of all running Explorers
find the right instance
change the active folder in that one
_thisFOLDER := "C:\Windows"
For $Exp in ComObjCreate("Shell.Application").Windows
if ( $Exp.hwnd = _thisID )
Thing is that Opus' 'Explorer Replacement' intercepts these calls and causes a failure.
Now I have to fall back to a different 'remote control' mechanism, which basically comes down to analyzing all components (controls) that make up the File Explorer Window, analyze their dependencies, find the right 'spot' to push and do so.
That is somewhat OK if it is about just changing he folder, but more advanced features like selecting a file in that folder will require even more "ugly code".
Therefor the question:
Is there a way to prevent Opus interfering with these calls?