I was able to get an extended trial license (thanks!) to add Directory Opus support for a tool I was writing and as I kind of promised to post the results in return ...
If you find any issues, please don't hesitate to post them as the trial license will expire and giving support after that will be 'tricky'.
What is JumpToFolder?
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.
(If you are not familiar with Everything: it's a very, very fast search tool for your files and folders on local as well as network disks with too many useful features to describe here. It is also free. Homepage: https://voidtools.com)
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 Directory Opus,
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 /file manager 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:
(based of File Explorer; Directory Opus uses the same mechanism)
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
JumpToFolder 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.
It is written in the AutoHotKey language.
Interesting. Thank you. But there is an issue when Explorer Replacement is activated in Opus and you try to use "jump to folder" inside explorer. Then this error is shown up:
When explorer replacement is set to off in Opus there is no issue.
The first time I tried to use the scipt in Opus the script got stuck. I could not open something of the seach result and could not use the left mouse button any longer anywhere. Had to force the computer to restart. After that it works now.
The list of supported file managers is not up to date in the config GUI.
Had again the issue that I could not select anything and after using esc to close the everything window I could not use the left mouse button any longer.
Win 11 Pro and newest Opus version. No idea how to reproduce it.
ok. It definetely happens when I try to use it in a save as dialog (which uses explorer, but the Explorer replacement setting in Opus has no influence to the failure in this case).
Stopping autohotkey in the taskbar solves the left mouse button problem.
Thanks for taking the time to test this, Mosed!
And especially for reporting the issues you found.
Will do a deep dive into this "Explorer Replacement". No experience with it (yet). Does it redirect calls to Explorer to dopus so you never get to see the Explorer window? Anyway, will figure it out.
That is unexpected .. to put it mildly. Are you using Everything 1.4 or 1.5? 32- or 64-bit? (they handle getting the file/folder differently)
Another thing I can think of is the speed of the processor. There are wait-loops in the code - there always are - and the timing might be off for very fast processors. It is tested by quite a few people with wide-ranging hardware setups, but worth investigating nonetheless.
Will try to come up with a solution anyway.
If this happens again, you could:
Press 'ESC' in the Everything window
Press 'ALT + F4' in the Everything window
switch to a different application using 'ALT + TAB'
Those actions should close the Everything window and also the JumpToFolder program.
Does that help? (not the solution, I know, just zooming in on the issue ...)
**
EDIT:**
Ok, that didn't work ... but gives an important clue.
Took a quick look at that code. Uses Everything.dll and IPC communication to get info out of the running Everything. That doesn't cause these troubles.
The Save As dialo that causes the mouse issue, which application does it belong to? (so I can try to reproduce). Does it happen in Notepad's Save As dialog too?
Now you mention it ... A couple of days ago I read somewhere that MS will change the file dialogs ("common item dialog") in the insiders build of Win11. Can't remember the exact details, though. Are you running the insiders build?
Not sure if that matters though, as you were already in the Everything window.
EDIT: False alarm .. that was about the OpenWith dialog.
Well spotted! Next update ..
I'm already quite busy this weekend, but hope to have an update on Sunday/Monday.
Short summary: More ore less: Yes.
Opus is then the default file manager. If you right click on a folder e.g. on the desktop you see that the standard behavior is "open with Opus". Every double click on a folder, shortcut, drive will be opened in Opus. When a program tries to launch explorer, Opus will take over.
But you can still open the Explorer with CTRL+E (at least as long as you do not change this also) and everything you do there stays in Explorer.
So if you use Explorer a double click will not be taken over by Opus.
So I guess your script has to take care that it changes/open the new folder path in the file manager from where it was launched and does not use the default (file manager).
Everything 1.4 - 64bit
The CPU is a AMD Ryzen 9 5900X - so quite fast, yes.
correct. It only helps to exit the autohotkey in the task bar. Nowhere else does the left mouse button work in this situation.
I can close the Everything window with ESC in this situation, but the left mouse button is not useable as long as the autohotkey is not terminated/ended (exit).
It was PDF X-Change editor. I tried it now again and also with notepad++ and it worked. I restarted the computer and it worked the first minutes. But now some minutes later it does not work again.
Same with Notepad++.
After some minutes I tried to use jumptofolder in the "open..." dialog of Notepad++ and it worked. Then tried "save as" - does not work. Tried directly again "open" and does not work.
I also get sometimes a message like "...path may be offline..." or similar. Which disappears sometimes without interaction.
What I also had as issue: Directly after reboot I got zero search results in Opus with Everything. It took some time until this worked. Same behavior sometimes after your script stucks. Search result is zero in Opus with Everything. Some seconds later with a new search I get results.
So perhaps there is an issue with the database on Win 11?
No. The official release.
Is there some log/debug mode I could use so that you would get information about the issue?
there are file-association for folders (HKCU\Software\classes\Folder (basic stuff)
There is a shell hook installed under HKLM\Software\Microsoft\windows\currentversion\explorer\shellexecutehooks that fires dopuslib.dll whenever a program calls ShellExecute().
When Explorer Replacement is disabled, dopuslib.dll will do nothing besides passing the call to the next in the hook chain. When it is enabled, it will do it's thing.
This does not intercept the starting of a new process (that is what WIN+R does, IIRC)
On my testsystem it's the only hook instellad here, so no issues with chaining (other applications might cut off the remainder of the chain if they think that's appropriate)
The "good" news is that I can reproduce the issue here with Eplorer Replacement enabled ("Replace Explorer for all files")
Working on it ..
I briefly checked if there was a mouse-hook installed too, but it looks like that isn't the case (not entirely certain, though)
Everything might be processing file updates it missed when not running. Or Windows might be installing updates; that causes a lot of files to be changed too.
In version 1.4 this is blocking and Everything is only usable after those updates are processed. In Everything 1.5 those updates are handled in the background.
When clicking a fiile that is on an off-line USBdisk or network drive that message will be shown.
Another possibility: Everything has a complete list of files on disk. When you select a file/folder you don't have access to, that message will be shown too. It should automatically disappear afer 3 seconds.
Everything has a debug log and a debug console (link). That gives very detailed information.
JumpToFolder has rudimentary debugging. You can enable it JumpToFolder.ini by changing debug=0 to debug=1
Note that you need to SHIFT-Click on the OK buttons (or press the spacebar), because the mouse-clicks are 'stolen'
I found a bug in the code. On line 321 it says "ClipWait".
That should be "ClipWait,1"
That will wait max 1 second for data to be posted on the clipboard. The original will wait indefinitely. That is bad practice ...
You can edit JumpToFolder.ahk in your favourite texteditor (Notepad++, I presume ;)) and see if that helps.
Tomorrow I (should) have time to write a debug version where you can interactively set a delay, so the program will pause a bit longer on critical parts.The idea is to figure out if it is indeed a timng issue (causing a race condition).
More details tomorrow.
It's unlikely to change for x64, but if there's an ARM version in the future it might have a different CLSID. Similarly the x86 version may have a different CLSID. And other shellexecute hooks exist in other software as well, of course.
If you need to detect it, looking up what the CLSID points to might be worth the extra step, since it's just one extra registry query. But using the CLSID should be OK, at the same time.
It is not offline and I have access directly via Everything without error messages. E.g. the C: drive or P: (cloud drive). All files and folders are accessible via Everything directly.
Perhaps here is the main issue. See below.
Yes, at least it solves the captured left mouse button. Thank you.
But I get a lot of "path could not be found. Perhaps offline" messages, which does not appear when I open the path directly via Everything.
But I cannot find out the pattern. I thought it is related to spaces or German special Characters. But that is not the reason.
After opening it via Everything it worked also in JumpToFolder (sometimes it needs several trials).
Sometimes it also works when I try it several times via JumpToFolder. After multiple "path not available" messages it is opened.
But I never get this message directly in Everything.
For e.g. this path it worked only after opening it once via Everything.
PS: Program Files is shown in adress bars as Programme due to German language, but I guess that is not the reason, because Everything is showing the English term and that works. And on P: Drive there is no difference in real path and shown path.
PPS: Issue exists also in Explorer. So it is not Opus related.
The debug=1 in the ini-file will step-through the process of getting and checking the path in detail. The titlebar/caption of the dialogboxes show the subroutine that is active at that moment. It should be able to pinpoint where this is going off the rails.
The code to get and check the path is pretty straightforward, so this really smells like a timing issue. Especially if it works on-and-off.
I just finished writing code to handle "Explorer Replacement" Opus.
Works well (at least on my older hardware .. )
Now adding 'slow-motion mode' ..
EDIT: : If you ENTER the filename instead of double-clicking it, do you get the same results? I expect so, but that also helps with zooming in.
Crazy. Now it works. Even after restart and the above mentioned pathes. I cannot reproduce it at the moment.
I reinstalled the chipset driver, but can this have an influence?
I tried is also in a VM which can use only 4 cores and there I got only sometimes the "path could not be found" message. Mostly all pathes were opened directly.
So the code is overtaking itself sometimes due to the processor speed?
Lets try a code with a small brake...
PS: Debug mode is active now. But cannot reproduce the issue at the moment... Sometimes I have to accept the windows with the spacebar, because the mouse button is captured by the script I guess.
Edit: After deactivating the debug mode I got one time again the "path could not be found" message. But not so often like in the past. So perhaps the debug mode works like a break....
The new " DopusDebug" version can be found here.
I can post the code here too, if that is more convenient.
Just overwrite the current JumpToFolder.ahk with this one and start using it; no need to re-run the settings.
When started, it will show a dialogbox where the delay in milliseconds can be given.
My expectation is that a delay of 10 - 20 milliseconds should suffice.
The handling of 'Explorer with Opus hook' is also included in this version.
A few other minor tweaks were added too; they should help with reliability in edge-cases.
I get now always the "path not found" message. The delay has no influence. Even when I first search and open a folder in Everything itself most pathes are not opened via JumpToFolder.
Same Problem with the 1.0.6 version. There were some updates for Win 11 yesterday. Does this have an influence? I will try it with the VM.
EDIT:
No Problem in VM. After restarting it works again. What was that? ^^
Some trials with "15" successful. But also with "0".
E.g. this path does not work at all via JumptoFolder, but via Everything.
C:\ProgramData\Acronis\ActiveProtection\.backup
Same for other pathes which have a dot inside the path. But in the VM it works. Very strange.
Explorer works now also with Opus explorer replacement active.
Edit 2: In save mode I could open all path. After restart I can now open the pathes also in normal mode. What is happening there?
After selecting a file/folder in Everything by double-clicking it, a dialog box like the one below is shown with the selected path between :
Is the correct path shown:
Always
Never
Sometimes
In the cases that the correct path is indeed shown, do you get the message "Path could not be found. Maybe off-line?"
(So the cases where the correct path is not shown can be ignored)
Always
Never
Sometimes
Hard to tell. Autoruns (by sysinternals/Microsoft) can tell which programs run at startup. Maybe one of these interferes? You can selectively disable/enable possible suspects in Autoruns.
BTW: Clever test, to run in save mode!
BTW2: Can't reproduce the 'dot-issue'. All tested folders with a "." in their name open without issues here.
.
When the path is found and opened it shows always the correct path in that dialog box.
When the "path not found" message appears there is always no path shown in the mentioned dialog box.
Is the path transferred from Everything to JumpToFolder via clipboard? Perhaps there is some issue due to another software?
Thinking about the possibility to have a live look into the clipboard to see what happens there... Or some general windows log about the actions in clipboard.
It is. After you double-click a result, JumpToFolder tells Everything to put the selected file/folder on the clipboard. When it is 'posted', double-quotes will be stripped of that path and a possible trailing backslash too. Then the FoundPath dialog will be shown. Nothing else happens here.
So you might be on to something. Check if you have some sort of Clipboard manager installed.
I also wrote a version that doesn't use the clipboard as it reads the entry from the resultlist by parsing the SysListView (the technical term for such a list), but that relies on the first column being the Name and the second one being Path (or a localized version of that, like Name und Pfad).
Using the clipboard gives more flexibility in that regard.
If you can't find anything suspicious, I will revert to the original 'SysListView-parser'.
BTW: For Everything 1.5 an entirely different method is being used. It is not affected by any clipboard issues.
I do not have a clipboard manager. I have screenpresso installed, but as long as I do not make screenshot it should not write to/change the clipboard.
At the moment it is working. Strange thing is that it is not reproducable. Sometimes it works, sometimes not under the same circumstances.
Do you have the possibility to define the columns of Everything when launching it? Then the SysListView variant would be "safe". But is also the question if it is worth to put so much effort in the old version. No idea when Everything 1.5 is final.
)
