It is short enough that that you probably would not notice it during testing, but when I press F2 then HOME with muscle memory, even though I don’t feel like I am doing it very fast, I hit this issue more often than not.
I press F2 with my left hand, and HOME with my right. Because I do this quite often, I tend to do it quite fast. Sometimes I press HOME before releasing F2 (which works fine in Windows Explorer and XYplorer), but I can also reproduce this by releasing F2 before pressing HOME.
So the delay may not seem like much, but when it comes to usability, I’d rate it with a fairly high impact.
Would changing the F2 hotkey to Rename INLINE=home fix things? That removes the need to push Home entirely.
I can reproduce what you're seeing but I have to push the two keys very close together; almost at the same time. Doing the same thing in Explorer seems to make it happen there occasionally as well, although it does seem easier to trigger in Opus, I agree.
I have seen something very similar. Restarting Opus and the video driver (Ctrl+Win+Shift+B) sometimes solves it, other times only a full restart. Please describe your system details (hardware/software) so that I may see if there is any common component that could be the cause of this (AMD CPU and GPU here).
Aside from this thread we don't have any similar reports, or any idea what's causing it at the moment. For it to go away after a reboot is odd.
It might be caused by a shell extension (ShellExView can list them and disable them; reboot or exit Opus via File > Exit Directory Opus after making changes), or an Opus script add-in (Preferences / Toolbars / Scripts). It could also be Opus itself, but without any similar reports that's less likely.
The machine running low on memory is another possibility, if it is starting to hit the page file and run much slower than usual. Next time it starts happening, have a look in Task Manager at resource utilisation for the system as a whole, and also dopus.exe in particular.
It does not entirely go away after a reboot. It just seems that sometimes the delay between pressing F2 and the UI updating increases up to 300-400ms. After a reboot that delay drops down but is still there, maybe 100ms or so.
I used ShellExView to disable all non-Microsoft extensions and restarted Directory Opus, but there was no change. I then rebooted, and as before the delay dropped down but is still there.
I have no Opus scripts installed under Preferences / Toolbars / Scripts.
I'll leave the shell extensions disable for a while to see if the delay increases again.
Looks like system-wide memory usage could become a problem, if more gets used up, but certainly shouldn't be a problem in the state it's currently in in the screenshot.
Something else I thought of:
Go to Preferences - Miscellaneous - Advanced
Set Troubleshooting / notify_debug to True.
Set shellchange_debug to True.
Download the small DebugView tool from Microsoft and run it. (If you see an error message about extracting Dbgv.sys you can ignore it as we are not interested in debugging device drivers.)
How much activity to you then see in DebugView?
If there's a steady but slow flow of notification events (e.g. maybe a page scrolls by every second or two), that's perfectly normal. But if there is a torrent of events, such that DebugView can't keep up with what's being displayed, then that might indicate where the slow-down is coming from. A huge number of non-stop change events can slow down the UI as it's having to process them all. (It has to be a really, abnormally huge number of events, though.)
If that's happening, there are some other settings which can be changed to try and mitigate it.
Either way, after doing the test, reset the notify_debug setting back to False, as leaving it on will slow things down even more.
If you want, make a manually-generated process dump and send it to us. We can take a look and see if anything looks unusual about what the process is doing or which DLLs have been loaded into it. It might not show anything, but doesn't hurt to take a look.
Crashdumps done and emailed to email@example.com.
I re-enabled my shell extensions and let Directory Opus run for a few days until I started to notice a bit of a slowdown. If needed, I can let it run for a few more days and generate some more crash dumps.
From looking at the process dumps, nothing looks immediately wrong, but there are a couple of things worth investigating:
Try removing any columns in Opus which might require opening files to calculate their details. (e.g. Description, Width, Height.) Similarly, disable any labels which do the same.
It was only present in one dump, but one had Opus waiting for a thread to start to calculate those details. (This could mean something is making thread start take longer than it should, rather than there being a problem calculating the details themselves. It may also be nothing.)
These are the non-Opus, non-Windows components loaded into dopus.exe:
One of those might be involved in the slow-down, but there isn't anything pointing to any particular one.
If it was happening on my machine, I might try disabling LastPass to see if that was involved, since the hook it installs presumably affects Edit controls, and F2 opens an Edit control.
Windows Defender has also caused a lot of strange delays over the years, especially if it's scanning new .exe files somewhere (even when it's a different thread that was looking at them), so disabling that might be worth a try.
One of the others could be involved as well, but I'm either not familiar with the other components or can't think of a reason they would affect how long F2 takes to open an Edit control. (Anything is possible, though, since each DLL is loaded into the process and can hook and run any code it wants.)
When it starts happening, does it tend to be in a particular folder, or where there are particular file types? e.g. Downloads, or EXE installer files or video files.
Thanks for the feedback. At the moment the delay after pressing F2 is minimal, so I cannot test for sure whether any of these changes will help. I need to wait for it to slow down again, which sometimes involves leaving my PC on for days.
Regarding the LastPass component, I have LastPass for Applications running, and enabled the option "Disable windows hooks". I am not sure if this is the component that was in Directory Opus, so I will generate another process dump and send it through for you to confirm.
Regarding Windows Defender, do you mean disabling it entirely, or is there a way to disable the shell extension?
Other than this, I will need to wait to see if it slows down again. At this stage I cannot say if only some files or folders are affected, but if it slows down again I will try to answer this for you.
That's a much smaller list than before. If you didn't disable all the other things, it might just mean the dump was taken before anything was loaded (e.g. before a window or Edit control was opened and triggered the various extensions and hooks to be loaded).
Windows Defender can potentially cause delays on any file access, so it would need to be disable entirely to test if it's involved.
Okay, I will try those things the next time I notice it slow down significantly. I do remember quitting Directory Opus (via File > Exit Directory Opus) it not making any difference, but I only tried that once.
I will send another crash dump shortly to confirm if the LastPass hook is in there or not, now that I left it running overnight and have used it a bit.