GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Slow response for right-click & context menu

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

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.

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.

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

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.

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)

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

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.

I'm sorry I have not played with WSH yet. That is one of my New Year's resolutions though.

[quote="kenalcock"]I'm sorry I have not played with WSH yet. That is one of my New Year's resolutions though.[/quote]Hello Ken...

You may want to look at the new Windows PowerShell, while you are at it: microsoft.com/windowsserver2 ... fault.mspx

I got the toggle switch to work, but I want to build this into a script function rather than the output of a VBE. I'm no expert in Visual Basic, and I tend to stay away from the language as much as I possibly can. However, included for those interested you will find my quick and dirty rewrite of my VB code. Feel free to pound it into the dirt.

Now Java on the other hand... if I didn't have to brush up on the JNI (Java Native Interface), I would have been all over this in just a few minutes.

[code]Dim Wscript = CreateObject("WScript.Shell")

CheckContext:
On Error GoTo CaptureEvent
Wscript.RegRead("HKEY_LOCAL_MACHINE\Software\GPSoftware\Directory Opus\ContextMenuDbg")
Wscript.RegDelete("HKEY_LOCAL_MACHINE\Software\GPSoftware\Directory Opus\ContextMenuDbg")
GoTo ContextMenuDbgEnd

CaptureEvent:
Wscript.RegWrite("HKEY_LOCAL_MACHINE\Software\GPSoftware\Directory Opus\ContextMenuDbg", "", "REG_SZ")

ContextMenuDbgEnd:
Wscript = Nothing
[/code]

So for those coders in VB, perfect this please. This will make my second attempt to program in VB.

Something I just noticed... (and possibly has to do with my computer more than anything) once I exit the debug mode and close the console, Opus closes completely. Anyone else experience this problem?

That's just how it works. (See the FAQ on debugging context menu problems.) You have to restart Opus to close the debug window. It's not really intended for frequent use.

That stands to reason. I must have overlooked that part of the FAQ. I'm working on the script to allow sending a string as a key with a value pair and registry type so I only need one script to handle toggling registry entries on and off. One thing I found very useful though, I found a VB script file written as a worm which authenticates as administrator group access for the local computer system to change registry entries. What's amazing about the worm file is that it was well documented (possibly after the fact). I will probably incorporate the ability into the final product (executable rather than script) but I will leave it out of the script.

I see this has turned into a quest to script things elaborately... and far be it from me to spoil the fun by 'dumbing it down' but FWIW I've done this for awhile with:

Button:

<button display="both" icon_size="large" type="three_button"> <label>Enable/Disable Contextmenudbg</label> <icon1>187</icon1> <button display="both" icon_size="large"> <label>Enable Contextmenudbg</label> <tip>Enable Contextmenudbg</tip> <icon1>187</icon1> <function type="normal"> <instruction>regedit /s /i &quot;c:\program files\jtools\contextmenudbg.reg&quot;</instruction> </function> </button> <button display="both" icon_size="large"> <label>Disable Contextmenudbg</label> <tip>Disable Contextmenudbg</tip> <icon1>187</icon1> <function type="normal"> <instruction>regedit /s /i &quot;c:\program files\jtools\contextmenudbgdel.reg&quot;</instruction> </function> </button> </button>
contextmenudbg.reg

[code]Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\GPSoftware\Directory Opus]
"ContextMenuDbg"=""
[/code]
contextmenudbgdel.reg

[code]Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\GPSoftware\Directory Opus]
"ContextMenuDbg"=-
[/code]

Thanks for the suggestion steje... that would work, but it's not along the lines of what I'm after. What I want is a good toggle method... one that I can turn on and off with the same information given. It just so happens the ContextMenuDbg is a perfect candidate for testing.

Hi Sprocket,
I haven't had time to follow this thread closely as it's a topic I have on my To - Do list, and also I'm quite busy now.
But, I can follow it, as I've done much of this in the past.
Ken does however seem to have an insight on the DOpus Zip comtext menu placement I need to look into.

Ken will probably cringe at this, but I know you're registry toggle can be done using a 4NT batch file.
4NT has a few variable functions that can be used to accomplish this.

@Regcreate -- create a subkey
@Regset -- write a value
@Regquery -- read a value
@Regsetenv -- Regset updating apps listening for changes

Edit Note:
These are variable functions in 4NT.
These are not DOpus related.
To use them one needs to specify the proper parameters [].
They are accessed by preceeding them with a '%' character.
End Edit Note.

The good thing is that your efforts leaning towards a free solution.
Java is still free from Sun I think as is WSH from Microsoft.
Luck Sprocket !

Regards,
Zippo

Thanks Zippo! I looked at the 4NT scripting, but I thought I could make it a bit more open/robust than that. I've succeeded with VB.NET (stopped at the fourth revision), C#.NET (second revision), and I'm now working with Java + JNI (my personal goal, I can read the registry). The major concern I have is safeguarding the values passed into the console app to keep from crashing the OS. So I'm building a safeguard routine which validates the recursive key structure of the registry before reading/writing/deleting the value pair of the registry. I've also built in an override mechanism using quiet and force flags. The Java version will keep the option open to support multiple platforms for this simple tool. I'm still debating on whether to keep the Administrator Override option. Even after changing the "Disable regedit32" in the Group Policy editor, I was still able to change the registry values using a guest group level account. Tested on Win2K Pro and WinXP SP2 Corp. If I released the software with this option, it would be a nightmare for administrators since it circumvents security.

My god... who would have ever thought editing the Windows registry through Java would be so involved. I built the native class functionality and wrapped a C++ DLL handler around the java files. The DLL handles the calls made to the registry and the Java source operates similar to using JDBC methods. If I can't find an easier way, I will stick with using C++ or VB.NET for the final console application.

Me. :slight_smile: