GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Right click menu extremely slow/delayed

I'm new to Dopus9, just installed it two days ago actually, and thus new to the forums. I did a search for my problem and couldn't come up with anything relevant to what my problem is, so here goes. My problem is when I right click on a file or folder, it takes roughly 5-8 seconds for the menu to appear. This isn't just files and folders in Dopus, it also does it on files on my desktop and such. BUT, when i simply right click the desktop or anywhere else (no file/folder selected) its instant, as it was for files/folders before I installed Dopus. Dopus runs fine in every other aspect though, fast and efficient. But this is extremely annoying. Any advice is greatly appreciated. I'm running Vista (32), 1gb RAM, 3500+ Athlon 64 processor, NVidia 6600 GeForce.

Do the menus appear quickly in Opus if you turn on Preferences, Miscellaneous, Windows Integration, Hide Windows items on file context menus (shift overrides)?

okay, that fixed the problem within Dopus, although its still having the delay outside of Dopus, on the Desktop for example. I've also noticed when i highlight a file on my desktop and press the delete key, it has the delay as well. but the menu's are working fine in Dopus now.

While anything is possible it seems unlikely that Opus is causing the delay, in that case. The option causes Opus to ignore all 3rd party context menus so it is presumably one of those menus which is causing the delay.

The Finding The Culprit section of this FAQ may help you track down which program's context menu is causing the problem:

[Crash, exit or high CPU when right-clicking certain files)

Basically, you turn off the "Hide Windows items" option that you just turned on, and also enable a debug setting, and Opus will then print a list of context menu extensions as each one is queried. With any luck one of the extensions will take much longer than the others (i.e. there will be a longer delay between it being listed and the next handler being listed) and that will point to the cause of the problem.

awesome, i pinpointed the problem and its been fixed. i went to the link you posted and found another link to ShellExView, which i used to disable/enable the context menus 1 by 1 and isolated which one it was, and it turned out to be RXDCExtShlExt extension, which is the Roxio Disc Copier Shell Ext. Not sure why it just happened when I installed Dopus though. but like you stated before, Dopus was not causing the delay. which is great, I love this program. thanks for your time though, I guess maybe if I'd read up some more on the FAQ i would've found that page and not wasted as much of your time, but patience is definitely a virtue i don't possess :stuck_out_tongue_winking_eye: sorry though, but thank you again :slight_smile:

Hi, I solved my right-click slow problem on my main computer windows, files, and folders by disabling the JustCloud context menu handler.

However, my dopus file windows still had the problem.

Of course, I was able to bypass it by setting the Preferences to "Hide Windows items". Then I decided to figure out which context menu handler was doing it, so I downloaded DebugView and ran it in administrator mode (by right-clicking debugview.exe), and then enabled the capture of everything.

However, when I run it, it only seems to pick up the Carbonite handler, and ignores the other ones (7-Zip, Edit with vim, Malwarebytes, etc). Is there some setting in DebugView that I am missing?

I suspect that it might be the Carbonite handler that is doing this, but I'd like to get a complete picture before I try disabling anything.

Thanks for a great forum!

P.S. I tried to attach the .LOG file from DebugView, but the forum wouldn't allow it: "The extension log is not allowed."

Don't run DebugView as administrator. DebugView should just be double-clicked and run normally.

That may be why you are not seeing things, as non-administrator processes could not send messages to an administrator DebugView for it to display.

(Try running DebugView normally first, as it is most likely that, but if you still only see Carbonite's entries then try these things as well:)

Did you turn on Preferences / Miscellaneous / Advanced: context_menu_debug? If you only run DebugView without turning that on then you won't see anything coming from Opus (but other programs may output to DebugView as well, which may be why you are seeing things from Carbonite).

It's also possible that all your other context menu items are added via registry entries and not by shell extensions, but that's really unlikely; you'd normally expect to see at least a few shell extensions if the debugging is turned on.

It only takes a moment to disable an extension using ShellExView so you might as well try it quickly, if you suspect a particular extension. If it doesn't make a difference, you can re-enabled it again just as quickly and then try the investigation steps.

If you put it in a zip archive, the forum will accept it (unless it is still really large).

Thanks for your prompt reply, Leo. It didn't matter whether I was in administrator mode or not -- the answer was in enabling Preferences / Miscellaneous / Advanced: context_menu_debug. Then the context menu handlers showed up (see attached zip file - administrator mode, but no Capture Global Win32 and no Capture Kernal), and revealed that, indeed, it was the carbonite handler causing the delay. DebugView said it was about .8 sec, but it seemed somewhat longer. I disabled the carbonite handler with ShellExView, and immediately the delay was gone. Apparently, there is some kind of error registered with dopus when the Carbonite handler is queried, and this causes two stack dumps and a minidump, which consume most of the extra time. When I right-clicked on the Desktop and in an Explorer folder, there was no delay (see zip file).

Thank you again for your guidance. This is definitely something I can live with, given that I can enable or disable the carbonite handler quickly and easily.
DAVID-SILVERMAN - dopus carbonite (7.19 KB)

The error and stack dump are coming from Carbonite (anything from Opus will have "dopus:" near the start of the message), so the best thing to do is report the problem to them for investigation.