DonationCoder.com Software > Post New Requests Here

[Request] Debugging Tool for Dynamic Verbs in Context Menus

(1/3) > >>

gr3gw:
In order to trim my context menu, I first need to understand where the entries in the menu come from. I've created pseudo commands for static verbs (under the shell key) that indicate where in the right click menu the shell verbs appear (see attached image). This is not possible with dynamic verbs (under shellEX) as the target program decides itself what name will appear in the menu, and if it will appear at all.

I would like to find or request a program that will display a name in the context menu. It doesn't have to do anything other then say, Yes include this in the context menu and provide a name. I need a pair for the ALL Files (*) key, a pair for the Folder key, a pair for the Directory key, and perhaps just one for the All File and Folder Objects key as I only need to see the start of these menu items. It is all the same program but each one is compiled with a different menu name.



Anyone attempting this program would need to be familiar with how programs are written for dynamic verbs. After that it should be quite easy, take an existing program strip out all the actual working code and change the name provided for the menu.

Suggested names are 'start shellEX All Files', 'end shellEX All Files', etc. The ordering in the menu can be controlled by the name given to the ShellEX command.

lifeweaver:
Hi gr3gw,

The ShellExView tool from Nirsoft will answer your questions, the tool includes a 'File Extensions' column with values like 'Directory', 'AllFilesystemObjects', and many file extensions.
This should help you understand where the entries are coming from.

MilesAhead:
It used to be simple to use 32 bit context menu shell extensions in 64 bit Windows.  You simply launched the 32 bit explorer.exe that is in the Windows\SysWow64 folder.  Not anymore.  MS changed it without any explanation I am aware of.  So now the choices are write a 64 bit extension and a 32 bit extension, or put the user in a position of using a 32 bit File Manager capable of using 32 bit extensions on 64 bit systems, or finding some tool that bridges the gap so that 32 bit extensions can be displayed in the Context Menu of 64 bit explorer.

The 32 bit extensions were made easier by a free wizard that would create the code skeleton for Visual Studio 6.  I have no idea if it works in the new editions of Visual Studio.  Also I am unaware of such a wizard implemented for free in 64 bits.

A different approach would be more feasible in my estimation.  Although not rocket science writing shell extensions that impement the IContextMenuN (where N is 1 2 or 3) series of interfaces has the frustrating side effect that on every test run explorer.exe hangs onto the DLL. Meaning you have to kill explorer.exe before you can edit and recompile.

A lot of work.

MilesAhead:
This utility seems a bit different than most.  It may be worth a look:
I think a 6 month license for 1 PC is $10

http://fcorp.bl.ee/product.php?page=cmm

gr3gw:
Thanks LifeWeaver. I have looked at NirSoft's ShellExView tool before but it does not neatly answer the question, Where does context menu item 'X' come from, when staring at a RCM menu. A complication with dynamic verbs (ones found in shellex/contextmenuhandler) is that it is the extension decides what name will be displayed (can be quite unlike what is used as the RegEdit key name) and whether or not it will appear. The reasons for appearing can be many but appear to include (1) the item is already in the context menu and so I won't display a duplicate, I'm not applicable in the current circumstances, etc.

My request is more akin to debugging programs by planting 'Here' statements in order to create a trace.

Navigation

[0] Message Index

[#] Next page