Rename delay after pressing F2

Help & Support
#1

I have noticed that there is a slight delay between pressing F2 (rename) and the file name becoming editable. I often press F2 then HOME to add some text at the start of the file name.

If I do this too quickly, the HOME key press changes the file selection to the first file in the directory.

Here is what should happen (renaming file3.txt):

slow

Here is what actually happens (pressing F2 on file3.txt then HOME immediately afterwards ends up renaming file1.txt):

fast

This works fine on Windows Explorer and XYplorer, so I do not understand why there is a delay between pressing F2 and renaming the file. With my workflow above, it ends up renaming the wrong file.

How can I have the HOME key press apply to the file being renamed?

#2

How long is the delay? If we're talking a second or so then that's definitely wrong and shouldn't be happening. If you have to hit both keys almost simultaneously then that might be normal.

#3

It is not horribly long... maybe 300-400ms.

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.

#4

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.

#5

Yep, seen it happen quite a few times, albeit I haven't timed all the pushes to know for certain where the fault lies.

#6

Yes, changing the F2 hotkey to Rename INLINE=home may help. I assume this is the same as the option:

Settings -> File Operations -> Inline Rename -> Default selection mode

Having said that, I rebooted my PC and now the rename is much quicker. The delay is barely noticeable now. I now have to type F2 and HOME very fast to create this behaviour.

I wonder what caused it to slow down before the reboot?

I also tried to reproduce this again in Windows Explorer, but no matter how many times I try, it seems to behave correctly every time.

So all I can say for now is that it still happens, with delay being almost instantaneous (but not quite) after the reboot.

#7

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

#8

I have an Intel CPU and AMD GPU (Radeon HD 7700).

I have attached a System Information file (from msinfo32.exe) showing all the hardware and software.

system.zip (141.6 KB)

I didn't know about Ctrl+Win+Shift+B, but I will try that the next time Directory Opus behaves this way.

#9

Are there any plans to fix this? The delay is sometimes still quite long when pressing F2, and I don’t understand why Windows Explorer and XYplorer don’t seem to suffer from this.

All it would take would be if F2 is pressed, delay processing other key presses until the UI catches up.

#10

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.

#11

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.

Memory / CPU usage looks fine.

image
image.png666×593 24.6 KB

image

#12

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.

#13

There seems to be nothing out of the ordinary with the debug log. As you wrote, I get a page or two of scrolling every few seconds.

I tried pressing F2 a few times, even repeatedly pressing F2 / ESC / F2 / ESC on a file, but there were no events logged at the point I pressed F2.

I have attached the log for your reference in case you spot anything unusual.

ZOLTAN-DESKTOP.zip (12.0 KB)

#14

That looks normal enough.

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.

#15

Crashdumps done and emailed to crashdumps@gpsoft.com.au.

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.

#16

Many thanks!

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:

    C:\Program Files (x86)\Dropbox\Client\DropboxExt64.27.0.dll
C:\Program Files (x86)\GeoSetter\GeoSetterShellExt64.dll
C:\Program Files (x86)\IDM Computer Solutions\UltraCompare\UC_ShellExt64.dll
C:\Program Files (x86)\LastPass\lastapphook_x64.dll
C:\Program Files (x86)\Microsoft Office\root\vfs\ProgramFilesCommonX64\Microsoft Shared\OFFICE16\MSOXEV.DLL
C:\Program Files\AMD\CNext\CNext\atiacm64.dll
C:\Program Files\Common Files\Apple\Internet Services\ShellStreams64.dll
C:\Program Files\Common Files\Autodesk Shared\AcShellEx\AcShellExtension.dll
C:\Program Files\IDM Computer Solutions\UltraEdit\ue64ctmn.dll
C:\Program Files\PDFsam Enhanced 6\context-menu.dll
C:\Program Files\TechSmith\Snagit 2020\DLLx64\SnagItShellExt64.dll
C:\Program Files\TechSmith\Snagit 2020\SnagItShellExtRes.dll
C:\Program Files\Windows Defender\shellext.dll
C:\Program Files\WinRAR\RarExt.dll
C:\ProgramData\Sync.Com DLL\rclick.dll
C:\Users\<username>\AppData\Local\Microsoft\OneDrive\19.174.0902.0013\amd64\FileSyncShell64.dll

    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.

#17

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.

#18

Something else to try next time it happens (after everything else, as it may mean the problem stops and you have to wait again for it to re-occur):

That might indicate if it's a condition inside dopus.exe or something outside it. (That won't tell us everything, but it might narrow down the types of things to look for.)

The new dump shows only these components loaded into the process:

C:\ProgramData\Sync.Com DLL\overlay.dll
C:\Users\<username>\AppData\Local\Microsoft\OneDrive\19.174.0902.0013\amd64\FileSyncShell64.dll

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.

#19

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.

#20

Here's what's loaded in the 7th dump:

C:\Program Files (x86)\Dropbox\Client\DropboxExt64.27.0.dll
C:\Program Files (x86)\GeoSetter\GeoSetterShellExt64.dll
C:\Program Files (x86)\IDM Computer Solutions\UltraCompare\UC_ShellExt64.dll
C:\Program Files\Common Files\Apple\Internet Services\ShellStreams64.dll
C:\Program Files\Common Files\Autodesk Shared\AcShellEx\AcShellExtension.dll
C:\Program Files\IDM Computer Solutions\UltraEdit\ue64ctmn.dll
C:\Program Files\PDFsam Enhanced 6\context-menu.dll
C:\Program Files\TechSmith\Snagit 2020\DLLx64\SnagItShellExt64.dll
C:\Program Files\TechSmith\Snagit 2020\SnagItShellExtRes.dll
C:\Program Files\Windows Defender\shellext.dll
C:\Program Files\WinRAR\RarExt.dll
C:\ProgramData\Sync.Com DLL\overlay.dll
C:\ProgramData\Sync.Com DLL\rclick.dll
C:\Users\<username>\AppData\Local\Microsoft\OneDrive\19.174.0902.0013\amd64\FileSyncShell64.dll