Slow response for right-click & context menu

Help & Support
1

Right-clicking to open the context menus is very slow. I compared it with Windows XP (SP2) Explore and found Explorer much, much faster--almost instaneous.

I've followed the discussions under the pertinent topics, have tried uninstalling troublesome XP security updates, and used ShellExView to try to locate contextmenus that are slowing things down. Using that utility I tried to remove OmniPage 14 context menu. It is removed from the Explorer but remains in DOPUS even after removing the key in the registry.

I don't know whether OmniPage context menu is the problem, but I'd certainly like to know how to speed up DOPUS.

Thanks,

rms

2

In my experience, response to DOpus right click is very slow the first time around and back to normal thereafter. It seems as if there is a one-time initialisation routine which slows things down.

Regards, AB

1 Like
3

Try this tip for speeding up (and organising) your context menus. You can add just the items you actually want and put them where you want them and all the other items don't cause a mess and don't slow things down:

[Tip: Organise and Speed-Up Context Menus)

I've configured things as in the tip and context menus appear almost instantly.

4

This is something I've often wondered about. When building your own context menus, what is the order of operations?

Meaning, do the Opus File Types take precedence over the File Type Groups and the System File Types?

If I want a menu entry for all folders to be located near the top of the context menu, and another entry to always be the last item in the list, how do I change the context levels for just the folders when there's the "files and folders" file type?

I'm trying to change the order of my menus so they are quite a bit less confusing and grouped more efficiently.

5

I'm not sure which order Opus adds the All Folders and All Files & Folders menus but I expect it's consistent so try it and find out. If the order isn't the way around that you want you can always not use All Files & Folders and instead only add items to All Folders and All Files (with items you want in both copied to both).

Context menus added by other apps and Explorer seem to be added in a random order. Probably comes down to the arbitrary order things are found in the registry. But you can sort that mess out using the tip, since it turns off all those menu items and then you add the ones you want back, exactly where you want them.

6

Hmm, I'm thinking feature request time. Wouldn't it be nice to have a weighted structure and a way to tell what context the menu option is coming from? Another would be "Ignore duplicate of same title" option... say, multiple "preview" listings. Also, what about taking order of precedence in a similar way to CSS or XML. Where files of all types follow a specific context menu unless the individual file type replaces a context option of the same title (hence, preview).

Top down look:
Files and Folders
Files
Folders
File Type Groups
System File Types

If a context menu setting is set globally for Files and Folders, but a similar entry for say... group Images differs, the context menu set previously for files and folders is overridden by the group Images context entry. If you have an oddball image such as a CDR (corel draw vector graphic), and you want the menu option from the group type images context replaced, it's just a matter of entering in another entry under the same title.

As the other option, a way to eliminate the context menu placement battle with a weighted system. By default the values for System File Types would have a weight of 0, but the files and folders weight would be 100. This way you could control the placement of the context menu option.

Last point, context administration... sort of like customize mode where you get to see the name of the group/entry/type used for the context sensitive menus.

Let me know what you guys think... then I'll post the feature request.

7

Using a weight or priority number seems like a decent, simple solution to defining the order of menu items.

I guess an option "replace item with the same name" may also make sense, but don't forget that context menus have to work when multiple files of different types are selected, as well. (In that case I'd expect the common entry to be shown, with the "replace with same name" more specific entry ignored.) Such a thing seems like a rare situation to me (at least, I've never wanted to replace a general item with something else in a more specific filetype) so I'd probably rather just have both items instead of have one replace the other.

8

Didn't know which thread to put this in, so I'm going with this one.

The position of context is awkward to work with. For instance, I can't get the Zip context in the location I want... it's always located before the All Files type and after the mimetype context. I tried placing the GUID into the context of the All Files and Folders, but the placement is always such that it is the first item in the list after the mimetypes. Disabling the context menu in the Zip Files (Opus Preferences) removes the options to Zip altogether.

Here's what I did...
Added a simple context menu option to All Files, Files and Folders, All Folders, and then added the mimetype context for Folders. The naming was kept very simple so I knew where each menu option was coming from. Because the Zip portion was not consistent, I left it off for this testing.

For those interested, don't forget to check the settings in Misc/Windows Integration and Zip Files in your Opus Preferences.

I created a simple filetype with the extension opstst. In the environment I put new folders (1, 2, & 3) and the files a.opstst, b.opstst, and c.opstst.

Now, the opstst is an unknown mimetype and contains 0 bytes, so only the Opus based menus would show. Right click on any of the files and I saw the following menu

All Files (context)

All Files and Folders (context)

This was expected. The folders were a bit different...

Open
Mimetype Folder (context)
Explore
All Folders (context)
Search...

All Files and Folders (context)

Now, I was thinking the mimetype and the All Folders context would somehow be right next to each other. I was also not expecting to see the Open, Explore, and Search... options either since I have the "Hide windows items on file context menus" active. I guess this only works with files, and not folders/directories. So this leads to another possible feature request (hide windows items on folder context menus).

I like the idea of a weighted context menu, but I think it can be changed so it's a bit more robust without much effort.

The location for All Files and Folders is where I would expect it to be. In this context I would add simple things such as "Properties" or the zip functionality. The top entry would be the mimetypes as those would change from day to day. followed by the mimetypes would be a tie between All Files ... and ... All Folders. After that, the Opus types section. Perhaps an easy way to make the weight system work is to apply the weight to each group as a whole, rather than individual items.

For those who are interested, I've saved my DFT files and attached them for anyone to test.
Test Filetypes.zip (2.76 KB)

9

I worked out the kinks of the wording and have sent the feature request in.

Cheers!

10

Q-1: Has anyone been able to reposition the Opus Zip context menu handler? I haven't been able to relocate this one.

Q-2: Does anyone else have PGP installed? I haven't been able to find where PGP hid there context menu handler.

11

PGP context menu appears to be {969223c0-26aa-11d0-90ee-444553540000} in the registry, but adding this with ContextForce doesn't seem to work so something odd is going on with it.

12

Aha! Now that I know what the bloody CLSID is, we can move it! The Default Value wasn't assigned to the PGP CLSID under the key. I believe FileType CONTEXTFORCE CONTEXTMENU looks for the Default Value. If you import the .reg file below into your registry, it should work.

[code]Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT*\shellex\ContextMenuHandlers{969223c0-26aa-11d0-90ee-444553540000}]
@="{969223c0-26aa-11d0-90ee-444553540000}"[/code]

Now anyway to relocate the Opus Zip handler? It does have a Default Value equal to its CLSID.

13

Oh, cool. :slight_smile: I didn't realise that would make the PGP handler work. Nice one.

I used to have to do FileType CONTEXTFORCE CONTEXTMENU={E9FE4040-3C93-11D4-8006-00201860E88A} to stop the Opus Zip menus being hidden by the "hide items on context menus" flag but I think that bug/behaviour has been fixed, maybe with the result that you can't move it anymore.

You could turn off the Zip context menus and instead define your own identical commands. (I don't think there's a way to simulate the "Add to xxx.zip" name of the items, but the functionality can be replicated.)

14

I haven't found a way yet. I kept trying to relocate the context but it still stays just after the mimetype context and before the file/folder context regardless of where you locate it. I would chalk the behavior to being a bug with the context menus.

15

I think it has more to do with Opus rendering it's own Zip Context menu (as a result of the Zip preferences) before processing the FileType CONTEXTFORCE CONTEXTMENU commands attached to Opus file types.

For experimentation's sake, when I was rearranging my context menu I attempted to force another context menu to appear twice. It doesn't work, only the first occurrence appears.

16

Yeah, I've already done that. I have a boat load of Zip issues to analyze, type up and file now!

17

Okay, this is actually quite niphty. I found the context debug mode (I did some reading).

Copied directly from the Opus 8.2 release notes:

[code]It is now possible to set the registry variable:
HKEY_LOCAL_MACHINE\Software\GPSoftware\Directory Opus
(String) ContextMenuDbg = ""

If this is set Opus will display a debug printout of all third-party context menu extensions as they are invoked (when pressing the right mouse button on a file or folder). If you have a context menu problem this should let you identify which context menu extension is causing the trouble, and you could then add its CLSID to the ignore list as above if desired. Remember to clear this registry entry after use.[/code]
Now then... it's time for me to create a new button for my toolbar... the setting and unsetting of a registry value.

18

There's some more info about the debug registry key in this FAQ on diagnosing context menu problems:

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

19

When you get your button worked out, post it back to this thread. That sounds pretty useful.

20

So far I've been able to add a String value to the registry as well as delete an existing entry, but I haven't been able to check for an existing entry yet. This is my first time programming in WSH (Windows Script Host). Any suggestions?

Scripting the WSH with the use of VB but it will be converted to a much more viable language once it's finished, probably C++ or I may use Java with JNI depending on how I'm feeling.