Interact with an Explorer window even when DOpus explorer replacement is active

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).

Explorer has a command line for doing that, I think. But this isn't a support forum for how to do things with Explorer. :slight_smile:

Of course the question is not how to do it in explorer, but how to avoid that DOpus is taking over.

I understand that such a command/call "select file in explorer" is captured by DOpus when explorer replacement is activated.

If someone has Explorer Replacement mode turned on, it's because they want to replace Explorer.

Yes, but you can still use explorer if you want to do it sometimes for some reasons.

And then there are two possiblities regarding Jump to folder (which is launched via context menu):

  1. disable it for the explorer (if Dopus is installed/explorer replacement is active)
  2. Bypass the explorer replacement when the user is explicitely using explorer instead of Dopus.

Option 1 is easy and at the moment the preffered solution. But perhaps there is a solution for option 2 which causes no big effort for the code. Then it could be an alternative.

Edit: perhaps the idea is not clear. :slight_smile:

  • if someone launches jumptofolder via context menu inside of Opus it shall be processed in Opus.
  • if someone launches jumptofolder via context menu inside explorer it shall be processed via explorer

But due to the shellhook, calls to explorer are captured by Opus (if NotNull wants to give the call to explorer to switch to another folder and select a certain file)

I don't think it's a good idea to start "if xxx is installed then no replacement". Then everybody wants a rule for everything and that will never end.

1 Like

I did not ask for a special exception only for this tool. :wink:

The question is if there is a general way to still call explorer events. Perhaps this is possible with a special code snippet or similar.

Either there is a general solution or no solution.

You can run explorer.exe directly if you want explorer.exe to do something, rather than the defaukt file manager to handle it.

Explorer.exe has a command line argument for selecting a file.

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

In code:

	_thisFOLDER := "C:\Windows"

	For $Exp in ComObjCreate("Shell.Application").Windows
		if ( $Exp.hwnd = _thisID )

Simple, straightforward.
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?

The Explorer windows will still be in that list of COM objects, if you want to do things via that route. They’ll just be mixed in with Opus windows.

Thank you!!
That was just the information that I needed; got it working now.
Update will follow soon...

1 Like