JumpToFolder - Use the power of Everything in File Managers and File dialogs

[NotNull]

Most recent version: 1.0.8 ( 2022-04-03 )
Download 64-bit version
Download 32-bit version

Read the installation instructions first.



What is this?
JumpToFolder is a utility, that makes use of Everything to jump to a different folder in file managers and file dialogs. All without browsing the intermediate paths.

So if your file manager is currently in folder c:\a\b\c\d\e\this and you want to go to x:\f\g\h\i\that, start JumpToFolder, type that in the appearing Everything window and select x:\f\g\h\i\that from the list. The file manager will change to that folder without further effort.

Or another example: you want to update the MP3 tags of an album, but can't remember where you put it or what it was called. All you can remember is that it has 'thunderstruck' on it. With JumpToFolder you can do the following:

• Right-click in an empty part of the list of files in File Explorer,
• Select JumpToFolder,
• Everything will open; type part of a foldername or file,
• in the resultlist, double-click or press ENTER on the file/folder of your choice
• Done!

The file dialog /filemanager will automatically jump to the folder you selected and will select the file you chose
(not yet in the version that was used for the following demo, btw.).


Demo:

JumpToFolder.gif (201.38 KiB) Viewed 183905 times

(Note: Everything typically responds *a lot* faster to search queries; the screen capture software makes it look slower)



Supported filemanagers
Beside Open/Save file dialogs, the following file managers are currently supported:

• Windows Explorer / File Explorer
• Altap Salamander
• Directory Opus
• Double Commander
• Free Commander
• Q-Dir
• Total Commander
• XPlorer2
• XYplorer

Total Commander and XYPlorer integration requires some extra steps. Details are in the Advanced Options section.


JumpToFolder is written in the AutoHotKey language.
It does not run in the background as it is activated by the "Jump To Folder" context menu entry. After switching the folder, it will close itself. That makes it very resource-friendly.



Installation and Configuration

• If you are using 64-bit Windows, download the 64-bit version of JumpToFolder
  Downloadlocation is at the top of this post.
• If you are using 32-bit Windows, download the 32-bit version of JumpToFolder (see above)
  Downloadlocation is at the top of this post.
• Extract the archive to a folder.
  The settings-file will be placed in that same folder, so the folder must be writable.
• Start JumpToFolder.exe
• In the left pane, select Settings
• In the right pane, fill in the settings that match your system and preferences

  

  2022-02-22 21_15_02-JumpToFolder settings (version 1.0).png (16.04 KiB) Viewed 183834 times

• Make sure Save & Install Context menu is selected in the Action field
• Press the OK button
• Done!

Uninstall

• Start JumpToFolder.exe
• In the left pane, select Settings
• In the right pane, select Uninstall from the Action dropdown list
• Press the OK button
• Done!

Advanced options


Special Everything setups

For most people running Everything, the following will not be needed. Everything 1.4 as well as 1.5 are supported out of the box. Installed versions as well as portable installations.

When you manually configured Everything to use a named instance, for example "My work", you can change the everything_instance="" setting in JumpToFolder.ini to everything_instance="My work".

For even more 'exotic' setups, there is a start_everything INi-entry.
One could look like:
start_everything='"..\some folder\everything64.exe" -instance "%COMPUTERNAME%" -config "%COMPUTERNAME%.ini" -db "%COMPUTERNAME%.db"'

If you use a similar exotic setup, please describe your setup (foldernames where your JumpToFolder is and also the paths to your everything.exe, database and ini-file) and I will provide you with the correct syntax for this entry.

JumpToFolder filter
If you define a 'JumpToFolder' filter in Everything, that filter will be used. If it's not available, the default (Everything) filter will be used.
In the JumpToFolder filter, you can define which paths to use or which paths to exclude. Also search modifiers like Match Path can be configured here.
An example (using Everything 1.5; version 1.4 has less options for filters)

2022-02-28 14_40_56-JumpToFolder filter .png (11.78 KiB) Viewed 183670 times

Total Commander
For Total Commander, an alternative way to start JumpToFolder is needed, as Total commander will never show the "Jump To Folder" context menu. Starting JumpToFolder in Total Commander can be done through a button on the button bar:

• Start JumpToFolder.exe
• In the left pane, select Applications
• In the right pane, click the Generate Button Bar code button.
• Close JumpToFolder
• In Total Commander, right-click on the horizontal or vertical button bar
• Choose Paste
• Done!

Now you can click the new button to change folders in the active tab.


XYplorer



Known limitations

• Off-line files and folders
  When double-clicking a file/folder, a check is done if that file is accessible. When files are on an off-line USB-disk or off-line network folder, it can take some time before Windows will report this file to be unavailable.
  
  Workaround is to create a JumpToFolder filter (see above) and add online: at the beginning of the Search field.
  online: is only available in Everything 1.5.
• Scroll-bar in Everything
  JumpToFolder has to intercept the mouse keys and the ENTER key in the Everything window, to prevent them from doing their usual job (opening files or folders).
  Side effect is that the scroll bar in Everything can't be used.
  
  Workaround is to press the SHIFT key when using the scrollbar.

- to be continued -

[NotNull]

- reserved -

[Coldblackice]

Awesome! I'm willing to be a tester if desired, although I'm not using non-English Windows.

[NotNull]

Version 1.0.6 has just been released. Download location and installation instructions can be found in the opening post.
Be sure to run the Settings GUI and save them, even if you did so already in a previous version.


Thanks to all testers: Coldblackice, EricB, horst.epp, LeoLUG, void and waffeln,
Very valuable input that made JumpToFolder a lot better than it was before!

[horst.epp]

For TC users which are not want to waste button bar space.
You can define an em_ command in your Usercmd.ini

Code: Select all

[em_JumpToFolder]
cmd=your_path_to\JumpToFolder.exe
param=-jump

Assign a hotkey like Ctrl-Shift-J to it under Configuration / Misc

Screenshot - 01.03.2022 , 10_50_27.png (10.35 KiB) Viewed 183633 times

[LeoLUG]

thanks @horst.epp
the cmd line, is not suppose to be direct to the lnk file instate of the exe?
It didn't work for me only after i made this change.

[horst.epp]

thanks @horst.epp
the cmd line, is not suppose to be direct to the lnk file instate of the exe?
It didn't work for me only after i made this change.

Why should I use the .lnk file ?
The .lnk file is nothing more than the exe with the -jump parameter.
Its of use if you have hotkey software which can't provide parameters.
My suggestion works fine here.

[LeoLUG]

for me, if using the code you posted (with your_path_to changed as needed) i got this msg:

2022-03-01_121440.jpg (12.42 KiB) Viewed 183605 times

if i direct the code to the exe, it works fine.

[NotNull]

I think @horst.epp has compiled the ahk script and therefor uses a different commandline.

You can use the command from the JumpToFolder shortcut in the program folder:

• Right-click JumpToFolder.lnk and choose Properties (Eigenschaften?)
• Activate the Shortcut tab
• Copy the entire Target field to the clipboard
  That will lookk similar to "C:\folder\JumpToFolder.exe" "C:\folder\JumpToFolder.ahk" -jump
• Use that for your [em_JumpToFolder] definition.

[LeoLUG]

@NotNull it works this way,
same as direct it to the exe and added the

Code: Select all

param=-jump

[horst.epp]

for me, if using the code you posted (with your_path_to changed as needed) i got this msg:
2022-03-01_121440.jpg
if i direct the code to the exe, it works fine.

I don't understand.
My code uses the exe and you said it doesn't work
but then you say using the exe works ?
As NotNull said I always compile AHK scripts and use the exe.

[LeoLUG]

sorry, i made a mistake on my last post, it's works only by using the link!

[ovg]

LeoLUG

It's seems that you're doing something wrong: em command by horst.epp working fine (w/o .lnk file)....

[LeoLUG]

maybe, here all the settings and files location

2022-03-01_141422.jpg (433.85 KiB) Viewed 183587 times

and here are the msg i got by using the shortcut

Video_2022-03-01_141700.gif (1.55 MiB) Viewed 183587 times

[ovg]

LeoLUG

It is impossible to read error message from you attached screenshot ....

[LeoLUG]

LeoLUG

It is impossible to read error message from you attached screenshot ....

[ovg]

LeoLUG
Please show definition of you em_JumpToFolder in user.ini

[LeoLUG]

on the above pic on the top left side you have it.

[ovg]

LeoLUG

Hmm... I didn't find anything wrong so far ...

[ovg]

LeoLUG
Please show content of your JumpToFolder.ini

[LeoLUG]

here

Code: Select all

[JumpToFolder]
everything_exe=C:\Tools\Everything 1.5a\Everything64.exe
also_search_files=1
sort_by=Run Count
sort_ascending=1
contextmenu_text=Jump to Folder ...
contextmenu_icon=C:\Tools\Everything\Everything64.exe,0
detected_everything_version=1.5
everything_instance=""
debug=0

[ovg]

LeoLUG

Sorry, I haven't any idea ....

[LeoLUG]

No problem, especially it works with the path to the .lnk file...

[NotNull]

I will think about offering the compiled version instead in the future. That would make things easier for everyone.

Couple of reasons why I didn't:
- people really should not run executables from some random dude.
- I wanted to host the program on this forum initially and didn't want to waste void's bandwidth and thus money.
But now all code is on GitHub, that is no longer a problem. At least .. not *my* problem


BTW: Should I post about JumpToFolder on the Total Commander forum too? Any opinions?

[LeoLUG]

BTW: Should I post about JumpToFolder on the Total Commander forum too? Any opinions?

Yes - my opinion.

[horst.epp]

BTW: Should I post about JumpToFolder on the Total Commander forum too? Any opinions?

Yes of course.
I guess there are many possible users for it.

[Mosed]

Great idea.

I have an idea for a possible enhancement: If the user selects a file in the Everything search window this file could be selected after jumping to the related folder.

So the tool could be a "jump to folder or file".

[NotNull]

Thanks for your (good!) suggestion, Mosed!

I was already working on that, but that failed due to Directory Opus ..
(I assume you are the same Mosed from the Opus forums?)


Directory Opus has an Explorer Replacement mode where all 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).

In a couple of days I will post the current working code (that supports Opus) on the dopus forums.
That will very likely be the last version that supports Directory Opus as I don't see a decent way around this shellhook. Sorry.



BTW: that "also select the file"-mode will not be used in File dialogs, as it is uncertain if the selected file will match the filter (like "Files of type: Text Documents (*.txt)" ) and therefor it isn't sure if that file is even shown in the list.


BTW2: QuickSwitch will support Directory Opus too (there were quite a few requests to support Opus).
Have found a solution/ decent workaround for the initial Explorer replacement problems.

[meteorquake]

With a similar effort one could press the shortcut for everything, get to the item you want, Ctrl-Shift-C, Esc and Ctrl-V.

What I think Everything would benefit from though is a keyboard shortcut to copy not the full path but the parent path (with trailing slash) - or is there such a thing? I've often wanted one...

David

[Mosed]

(I assume you are the same Mosed from the Opus forums?)

Yes. I wrote there some PM to you, but there were no response. So I thought perhaps I should try it here.
I still have with everything 1.4 and the clipboard-variant the issue with "path not found". But it is not really reproduceable. So I switched to Everything 1.5 (and changed your code to not get the dialog boxes for the delay choise and path found information)

Directory Opus has an Explorer Replacement mode where all 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).

In a couple of days I will post the current working code (that supports Opus) on the dopus forums.
That will very likely be the last version that supports Directory Opus as I don't see a decent way around this shellhook. Sorry.

Did you ask the Opus team how to avoid that Opus is doing that? I think there must be a way, because also in other areas you can still use explorer beside Opus.
Is it not possible to adress directly explorer? Via contect menu you can open folders with exlorer if you choose "open with explorer" as far as I remember. So there must be a way to bypass the Explorer Replacement.

So like "If (jumpToFolder was started via Explorer) open folder/select file in (explorer) else if (...)"
That is not possible due to the shell hook? Perhaps Opus Team can help.
Perhaps they can even improve Opus to give this possibility in future - they are open to such things. Would be a pitty if jump to folder is not supported in future in Opus.

Or another idea: If explorer replacement in Opus is activated deactivate Jump to folder in Explorer/other file managers (at least outside of file dialogs, they are not affected by explorer replacement). Would that be an easier workaround?
I think we should primary avoid error messages or crashes.

BTW: that "also select the file"-mode will not be used in File dialogs, as it is uncertain if the selected file will match the filter (like "Files of type: Text Documents (*.txt)" ) and therefor it isn't sure if that file is even shown in the list.

Would it be possible to read out the current filter in the open dialog? Then there could be a if else code which considers this.
No idea how complex this would be.

[NotNull]

Yes. I wrote there some PM to you, but there were no response.

Yeah .. those messages end up in my "forum mail-account", which I don't really keep track off.

Did you ask the Opus team how to avoid that Opus is doing that? I think there must be a way, because also in other areas you can still use explorer beside Opus.
Is it not possible to adress directly explorer? Via contect menu you can open folders with exlorer if you choose "open with explorer" as far as I remember. So there must be a way to bypass the Explorer Replacement.

Opus steals the ShellExecute() calls, but leaves the CreateProcess() - to start a new process/program - alone.
Open with Explorer uses the latter.
When you want to interact with an already running File Explorer, CreateProcess() will not do, unfortunately.
There is not much the Opus developers can do here.

Or another idea: If explorer replacement in Opus is activated deactivate Jump to folder in Explorer/other file managers

I like that idea!
When starting JumpToFolder in File Explorer, just show a dialog like "Not supported as Directory Opus is installed"
(Other filemanagers can still be used, btw.)
Easy to implement and saves a lot of headache. Good idea (why didn't I think of that ...)!

Would it be possible to read out the current filter in the open dialog? Then there could be a if else code which considers this.
No idea how complex this would be.

That will get complex.
On the outside It looks like all File dialogs are the same, but under the hood they can differ a lot (it took 7 differet algorithms to finally find one two that supports all. And I'm pretty sure I will have to write an 8th algorithm at some point because of yet another different dialog...
But will consider it.


Thanks for your feedback!
(I had given up on dopus, but you changed my mind)

[Mosed]

Or another idea: If explorer replacement in Opus is activated deactivate Jump to folder in Explorer/other file managers

I like that idea!
When starting JumpToFolder in File Explorer, just show a dialog like "Not supported as Directory Opus is installed"
(Other filemanagers can still be used, btw.)
Easy to implement and saves a lot of headache. Good idea (why didn't I think of that ...)!

ok. great.
Two questions about that:
- will JumpToFolder then still work in file open/save dialogs? Opus is not stealing there anything...
- is it possible to deactivate jump to folder in explorer only if explorer replacement is activated? Perhaps it is possible to check for the shellhook? For me not relevant, because I use explorer replacement, but perhaps this would be nice for some other people.


To understand it: Why is this not an issue for additional installed other file managers? I think this should not really be often the case, perhaps as long as somebody is testing several file managers. But if somebody installs Opus and XYplorer, activates explorer replacement in Opus and tries to use jumptofolder in xyplorer there will be no error message?

[NotNull]

Two questions about that:
- will JumpToFolder then still work in file open/save dialogs?

Yes. Like you said: Opus is not stealing there anything...

- is it possible to deactivate jump to folder in explorer only if explorer replacement is activated? Perhaps it is possible to check for the shellhook? For me not relevant, because I use explorer replacement, but perhaps this would be nice for some other people.

I already check for the shellhook. The way Opus implements it: Right upon installation of Opus, the shellhook is installed, regardless if people are using 'Explorer replacement' or not.

As soon as someone/some program does a ShellExecute() call, it is redirected to all programs that have a shellhook installed. These programs form a "chain": the first one "does it's thing" and passes his 'token' to the next one in the chain. Or decides that all is OK and cuts off the rest of the chain; in that case the other programs never get to do "their thing".

When the token arrives at Opus (opuslib.dll is responsible for handling), it checks if the current Opus user has 'Explorer replacement' enabled. If it isn't, Opus does nothing beside passing the token to thenext in the chain.

So the shellhook is always there, but what happens depends on the 'Explorer replacement' settings.
And that is hard to detect. There can be multiple Opusses active; ini-settings can be everywhere; there could even be Opus instances running under differetn useraccount.
All that will end in a game of 'settings-hunting', which I likely will lose.

To understand it: Why is this not an issue for additional installed other file managers? I think this should not really be often the case, perhaps as long as somebody is testing several file managers. But if somebody installs Opus and XYplorer, activates explorer replacement in Opus and tries to use jumptofolder in xyplorer there will be no error message?

Correct.
Explorer.exe is a special case as it is the shell (Desktop) as well as a file manager (File Explorer)
ShellExecute calls are handled by .. you guessed it .. the shell. And that is explorer.exe.
Other file managers do not have this issue. I have about 40 [1} file managers on my system and they all live happily together without Opus interfering (as far as I tested at least).
So Xyplorer and other file managers work perfectly fine with JumpToFolder, even if Directory Replacement is enabled.


[1} Minus 1 : in the meantime the Opus trial license expired ; working on a solution ..

[Mosed]

ok. I think then there are two possibilies for the case that DOpus is installed:
- deactivate JumpToFolder in Explorer completely
- only the base function JumpToFolder is available, but not JumpToFile or further enhancements

You wrote already the code for the second option, so perhaps you want/can keep it. But perhaps the code gets too complex then because you have to do different things in explorer depending on DOpus installation.


Regarding Opus license I see some possibilites:
- Buy it.
- Install it in a VM which is resetted once a month (but I guess this is against the "terms and conditions")
- ask DOpus User to test your code changes (but that is not really comfortable)
- reinstall Windows and use again 30 days free trial
- I assume you already used the 60 days extended trial license.

Thank you for your effort. I assume programming is your hobby.

[NotNull]

ok. I think then there are two possibilies for the case that DOpus is installed:
- deactivate JumpToFolder in Explorer completely

That is what I am going to do (dialog "Not supported because DO is installed").

Regarding Opus license I see some possibilites:

- hack it

I know I can work around limitations, but indeed: it's not the decent thing to do. I respect the developers and their license conditions.
Luckily most external interactions with Opus are done through dopusrt.exe, so I can do a lot 'blindfolded'.

I assume programming is your hobby.

Not even that. I wanted to learn myself some programming and this seemed something that I could benefit from myself and maybe others too. And thanks to all the input and feedback I got from people like you, it is starting to become a real application. (Thanks for that, everyone!)

So this is the very first program I ever wrote. Would not even call myself a developer at this point.
It is indeed fun to do, but don't expect an update every week as that there a lot of other things that are fun to do too

(I expect to have a new version ready by Sunday)

[Mosed]

ok. sure. Your are doing it in your spare time. So no time pressure for updates...

I have allowed myself to raise two questions to the DOpus team regarding the main issues with explorer replacement. Perhaps they know a solution which is easy to use for you without ugly codes or workarounds. Would be nice if you can follow the topics and answer to responses if questions came up or similar.

https://resource.dopus.com/t/interact-w ... is-active/
https://resource.dopus.com/t/detect-act ... rom-extern

Edit: You can easily detect if explorer replacement is active via registry. See linked thread. Perhapy you want to consider it.

[NotNull]

Edit: You can easily detect if explorer replacement is active via registry. See linked thread. Perhapy you want to consider it.

Nice! I can work with that ... Thanks!

[Mosed]

@NotNull: According to dopus developer Leo it should be possible to give commands to the explorer directly via command line commands and using explorer.exe (instead of shellexecute).

Perhaps then there is a easy solution to "ignore" the explorer replacement?

Or what is the reason to use shellexecute calls instead of direct calls to explorer.exe?

See linked topic in DOpus Forum.

[NotNull]

Thanks! I did explain the situation over there.

[Mosed]

Ok. If you find still no way with a clean code then in my opinion the solution is to show in explorer a message with "Not supported due to activated DOpus explorer replacement" or similar (when it is activated).

40 file managers is a lot...

[NotNull]

Version 1.0.8 has been released.

Changes:

• Added support for Directory Opus
  All credits go to @Mosed here as he helped tremendously with the Directory Opus integration
  (if it wasn't for @Mosed, I would have dropped DOpus support)
• Added routine to select the file in file managers
• BugFix: could be waiting on clipboard change indefinitely under certain conditions
  (only in Everything 1.4)
• Improved timing

From version 1.0.8 on, JumpToFolder will be distributed in compiled form (JumpToFolder.exe).
The runtime is no longer needed and JumpToFolder.ahk can be deleted too

The shell integration changed due to this (different command to start JumpToFolder).
This means that it is needed to re-run the Settings part and confirm the settings (Save & Install Context menu).
This is a one time action; it is not needed for further versions.

Download-link is at the top of the opening post.



A request though:
JumpToFolder is now distributed as an executable.
In my opinion, people should not download and run executables from some random dude/dudette on the Internet.
Furthermore:VirusTotal reports that 2 (obscure) scan engines detect that this is/has malware (there always are ... ).
BTW: All other scan engines report this to be safe. And it is, although you also should not take my word on that.

To establish some form of trust, I will ask you to "star" JumpToFolder on GitHub if you have a GitHub account. I think 10 to 15 stars in total should be enough [1] to make it trustworthy for other people. You can stop starring after that.
Provided that you like JumpToFolder, of course


[1]I have to admit that this is just a wild guess as didn't delve into this (not interested in the "stars business").

[thepauler]

I use directory opus, but for some reason I haven't had any luck getting this to work in Windows 11. I'll try again with this release and report back.

[NotNull]

I use directory opus, but for some reason I haven't had any luck getting this to work in Windows 11. I'll try again with this release and report back.

Version 1.0.8 has been released.

Changes:

Added support for Directory Opus
Added routine to select the file in file managers
BugFix: could be waiting on clipboard change indefinitely under certain conditions
(only in Everything 1.4)
Improved timing

(No experience with Win11 yet. Will wait till it no longer has Alpha status )

[horst.epp]

The source is unfortunately still version 1.0.6

[horst.epp]

Tested your compiled x64 version.
Works fine here under Windows 11.
Tested with Total Commander, XYplorer, Free Commander.
______________________________________________________
Windows 11 Home x64 Version 21H2 (OS Build 22000.593)
TC 10.00 x64 / x86
Everything 1.5.0.1305a (x64)
XYplorer 23.00.0006

[Mosed]

I use directory opus, but for some reason I haven't had any luck getting this to work in Windows 11. I'll try again with this release and report back.

For me it works. Also 1.0.6 worked for DOpus 12.x.

[NotNull]

Tested your compiled x64 version.
Works fine here under Windows 11.
Tested with Total Commander, XYplorer, Free Commander.

Thanks for testing! Glad that it works allright. BTW: allergic to File Explorer?

The source is unfortunately still version 1.0.6

You are very quick! I updated the ahk code an hour ago (posted the releases first and those had to be tested before uploading the ahk-code)

Ahk version should now be 1.0.8 (or else 'CTRL + F5' in your browser)

[horst.epp]

The source.zip is still the old one even with another browser.
The dir name in the source code says 1.0.8 but the ahk file is old, also in the tar.gz file.

I downloaded the master zip file which is the new one and compiled it.

Tested now also with Explorer

[NotNull]

The source.zip is still the old one

Oh, *that* is what you mean ..
I didn't add the source file, GitHub did. And as I posted the releases before uploading the .ahk, GitHub did not include the ahk, I guess.
Lesson learned for the next release (don't think that can be fixed right now). Well spotted

Tested now also with Explorer

I knew you could overcome yourself Thanks!

[Mosed]

Also in the previous version we had to run an exe to activate Jumptofolder. Where is the difference to the new version? The exe contains also the code for the jumping itself I assume, but you had to trust in the exe anyway. Right?