Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us
topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • February 13, 2016, 03:22:59 PM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: [Request] Debugging Tool for Dynamic Verbs in Context Menus  (Read 1188 times)

gr3gw

  • Supporting Member
  • Joined in 2007
  • **
  • default avatar
  • Posts: 8
    • View Profile
    • Donate to Member
[Request] Debugging Tool for Dynamic Verbs in Context Menus
« on: August 23, 2015, 04:23:05 PM »
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.

Special labels in RCM context menu.jpg

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.
« Last Edit: August 23, 2015, 04:38:48 PM by gr3gw »

lifeweaver

  • Member
  • Joined in 2014
  • **
  • Posts: 22
    • View Profile
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #1 on: August 31, 2015, 01:00:55 PM »
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

  • Supporting Member
  • Joined in 2009
  • **
  • Posts: 6,670
    • View Profile
    • Miles Ahead Software
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #2 on: August 31, 2015, 05:22:08 PM »
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

  • Supporting Member
  • Joined in 2009
  • **
  • Posts: 6,670
    • View Profile
    • Miles Ahead Software
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #3 on: August 31, 2015, 06:00:12 PM »
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

  • Supporting Member
  • Joined in 2007
  • **
  • default avatar
  • Posts: 8
    • View Profile
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #4 on: September 02, 2015, 05:02:16 PM »
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.

gr3gw

  • Supporting Member
  • Joined in 2007
  • **
  • default avatar
  • Posts: 8
    • View Profile
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #5 on: September 02, 2015, 05:09:33 PM »
Thanks MilesAhead. I wasn't aware of the 32/64-bit complication. Sounds like this might further complicate RCM context menus which, after all, are meant to make life easier.

I didn't know about Context Menu Manager by Fahmy (http://fcorp.bl.ee/product.php?page=cmm). At first glimpse I don't think it will do what I'm looking for but I will investigate further.

What I've requested is a debugging tool. Ideally, for those interested in such matters, we really want a tool that would 'compile' context menus for any file or folder type and show use what the context menu would look like before it is implemented. :-) This is not going to happen though.

worstje

  • Honorary Member
  • Joined in 2009
  • **
  • Posts: 571
  • The Gent with the White Hat
    • View Profile
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #6 on: September 02, 2015, 06:32:53 PM »
This topic just now caught my eye by sheer chance. As someone who has gone into very nasty territory with regards to properly recreating context menus in as authentic a manner as possible (look up Cautomaton if you're interested), I can tell you one thing: rocket science is more predictable.

Back before the Windows XP days, there was no API to properly summon a context menu. During some version of Windows XP, there was an internal API that got published as a part of a lawsuit deal in the EU, although it was hardly the most suitable thing. Around Vista, a 'better' API came out, and iirc Windows 7 improved on even that with yet more miracles. Even the latest API is not easy to use, and the ones before that are pure hell.

What I can tell you based on my experiments is that the ordering is both directly and indirectly based on the OS. Why indirectly? Because of those APIs I mentioned. Some of the old ones expect the calling applications to pass the relevant registry keys to them in an array... and the ordering of said array alone can shuffle things considerably. Throw in that the Windows versions actually brought in new features and other messes, and there is no such thing as a simple 'order' for context menu items. Of course, all this still ignores the marvel of the schzophrenic 32/64 bittiness that others have already mentioned.

Probably the most unreliable part of it all are the shell extensions that get loaded. In theory, it ought to be relatively simple in how they are implemented. But programmers do silly things out of sheer incompetence (or to please their bosses). Combined with all the differences that already exist between the Windows versions, these shell extensions can behave wildly different depending on the Windows version, even if they aren't version sniffing.

(And this is the point where I read some more posts in the topic and realize what you were really asking for...)

I think that the stuff you are looking for is really hard to do. Ignoring the wildcard that is dynamic verbs that could screw everything up, some results are possible.

For static verbs, it is basically a matter of automating what you do manually already in the various places (extension / file 'class'). Don't forget to keep an eye on the mime type (or wtf the registry key is called); it also affects the menu items that pop up (although this stuff may actually end up being dynamic, now that I think of it). Since it is pretty much all static in nature, there's no need to simulate anything and the registry gives you your answers.

For dynamic items, it is possible to manually try and figure out what the shell extension modules are, and then manually run them and try to create some results. But false positives would run rampant: ideally you'd want to feed it an empty context menu so that all the things it adds are the ones you are interested in. But if it does sniffing ('put me right underneath send-to' logic for example), that stuff could really backfire and it might not sniff up any items whatsoever.

I know this shit has given me many headaches, and my successes are completely based on tenacity and the blood and tears of others who have tread the path before me. Either way: what you want is not something that is a simple matter of just tearing out existing code. It involves recreating the Windows internals regarding context menus with enough precision to stave off all sorts of awkward edge cases. Even if a lot of the context menu could be simulatedly recreated using a 'phantom' file that kind of matches the criteria you are looking for, it will break, and you won't have your neat separation of 'X is located in All Folders, Y in All Directories, etc'.

All that said: I do not want to discourage you. But the depths of context menus are where masochists venture in need of their fix. That's all. :)

gr3gw

  • Supporting Member
  • Joined in 2007
  • **
  • default avatar
  • Posts: 8
    • View Profile
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #7 on: September 03, 2015, 02:53:07 AM »
Thanks worstje. You've added to the scant information that I've gleened for myself through experimentation and you've made me feel a lot better about not being able to fathom it.

When I said that a 'compiler' for context menus would be ideal, I was not really asking for a compiler but trying to illustrate why my simple 'logic tracking' mechanism would suffice. Before event-driven programming, we used to debug programs by adding extra statements to programs to display the path the program was actually taking. We often used print statements to display messages like 'Here 1', 'Here 2', etc. Using such statements we could see the the logic path the program was actually taking and thereby find the bugs in our programming.

Let me see if I can restate the requirement. Lets call two of the required programs CMtrackerID1 and CMtrackerID2

In the registry, the tracker programs are invoked at the start of the shellex sequence and at the end as follows:

shell
...
shellex
   contextmenuhandler
        CMtrackerID1 (Default value: CLSID of tracker DDE)
        ...
        avast
        Notepad++
        ...
        CMtrackerID2 (Default value: CLSID of tracker DDE)
...

The definition of CMtrackerID1 as follows:
* insert a menu item in the context menu with name '000 CMtracker START'
* add the menu item always, that is ignore the context
* no need to do anything else, it's a null action.

The definition of CMtrackerID2 is the same as CMtrackerID1 except it displays the menu name '999 CMtracker END'

What we see when the context menu is invoked is,Mockup of context menu with tracker info.jpg[Request] Debugging Tool for Dynamic Verbs in Context Menus

There needs to be two programs (CMtrackerID1 and CMtrackerID2) because there is no way to pass an argument to the DDE that I know off.

These two programs can be used as follow.
  • Insert the programs in the shellex part of the registry definition of a context menu to be examined, eg Directory.
  • Use Explorer, or what ever file manager is preferred, to observe the effect of shellex components

It may be a long and tedious method of examining context menus BUT it will be possible with a large amount of reliability, something that is not currently available.

Notes:
1. The tracker menu names start either '000' or '999' because I suspect Windows does some sorting on the menu item names and it's important that tracker appears at the start or end of a section.
2. In the example, will Avast come before Notepad++ or after? I think it depends on the menu name the programs pass back and whether or not they are sorted. The menu item names are 'Scan <filename>' for Avast and 'Edit with Notepad++' for Notepad++. This question and many others can be answered with the CMtracker programs.
             

worstje

  • Honorary Member
  • Joined in 2009
  • **
  • Posts: 571
  • The Gent with the White Hat
    • View Profile
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #8 on: September 03, 2015, 05:25:00 PM »
I understand what you mean, but my point is that it is not as reliable as you think it is.

For one, context menu handlers do tons of disgusting shit they should not do when adding menu items, so the order in which stuff appears has zero bearing on where you see it in the list.

Second, context menu handlers have a habit of fucking around the moment stuff gets actually displayed / drawn, which only gives them more ability to screw with the ordering and presence of menu items. (Probably ought to fall under point 1.)

Third, the order in which Windows executes the context handlers is unknown / unspecified, which will affect the stuff in the first few items only more. A bug in a single context menu handler can affect others, and errors can cascade with the most confusing shit to debug for a programmer. (You and your target audience may well be smarter than me, but I've found it a good practice to always idiot-proof stuff as much as possible. This stuff alone makes me anticipate a lot of bug reports that are nor ever were mine to fix.)

From the points made upto here, it follows that even a minimal, perfect implementation of your two shell extensions could actually affect the ordering/display of menu items. (For example, assume that a shell extension moves all of its items into a submenu whenever there's more than 20 items displayed. Shenanigans would happen if you bump it over that magical number!)

Fourth... temporarily dumping stuff in the registry, running a test and then unregistering it is prone to error. Your program might crash and your users might be stuck with the things. Maybe you remove it in an improper fashion. It might somehow interfere with other programs on their computer, or those programs might interfere with you. All of it comes down to you trying to solve a local problem with a global solution, and that shit is poison.

In the end, keep in mind that whatever you do, when you deal with context menus you are dealing with shell extensions, and it wouldn't be surprising if there's a dozen shoddily coded context menus that interfere with eachother that you do not have the source code for to inspect. You do not really have the code Windows uses to build  the context menus either. All you have is an understanding of the API, but you do not have an understanding of the way either side violates the API! (Programmers are idiots, and Windows breaks stuff in a gentle way to try and guard against it. It's madness!)

When you know so damn little, how useful are your print debugging statements really? While I haven't taken your exact path of print debugging, but I did do a lot of print debugging whilst doing Cautomaton, and the results made sense as often as they defied it. :(

I feel the need to say this (again): I do not want to discourage you nor shit on your request. But I know first-hand that context menus are a nightmare that fall apart based on implicit assumptions. This stuff amounts to 20 years worth of hackery and abuse, and for all the simplicity it ought to be, it has turned into a terrific frankenstein of gotchas. Nothing is as it seems to be, and you do not know what you think you know.


...

Have fun?  8)

gr3gw

  • Supporting Member
  • Joined in 2007
  • **
  • default avatar
  • Posts: 8
    • View Profile
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #9 on: September 03, 2015, 06:44:45 PM »
Hi WorseJe,

Thanks for that comprehensive information. What you've done is confirmed that trying to organize context menus will be like herding cats, which is my experience so far.

The programs that claim to tame context menus are stretching the point. They help edit what is in the context menu but the user still needs to know what they want done else mayhem will result.

And how do they work out what they want done... better to forget it. :-) Some things are just meant to be that way. :-)

Thanks everyone.

worstje

  • Honorary Member
  • Joined in 2009
  • **
  • Posts: 571
  • The Gent with the White Hat
    • View Profile
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #10 on: September 04, 2015, 05:58:49 AM »
Well, it isn't meant to be that way. It just grew that way. With enough effort, anything ought to be possible. But that is imho something that requires a lot of time, effort and... money. (I think a commercial company would be the only one with enough staying powe to make it actually convenient to use and easy to understand...)

MilesAhead

  • Supporting Member
  • Joined in 2009
  • **
  • Posts: 6,670
    • View Profile
    • Miles Ahead Software
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #11 on: September 04, 2015, 07:52:55 AM »
Well, it isn't meant to be that way. It just grew that way. With enough effort, anything ought to be possible. But that is imho something that requires a lot of time, effort and... money. (I think a commercial company would be the only one with enough staying powe to make it actually convenient to use and easy to understand...)

Plus you have to figure Explorer has so many quirks that if it is ever fixed it will need to be a complete rewrite.  MS is ignoring it as long as possible.  But some day they may have to byte the bullet and do it.  Which will erase all the utilities that hook into it.  When it does happen it will likely be a surprise.  Who would invest in something with not much in the way of return?

gr3gw

  • Supporting Member
  • Joined in 2007
  • **
  • default avatar
  • Posts: 8
    • View Profile
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #12 on: September 04, 2015, 02:00:16 PM »
Thank you worstje and MilesAhead,

This discussion has, believe it or not, taken me forward on how to deal with context menus, particularly the dynamic verbs created through shellex\contextmenuhandler.

My new approach will be to manually map out what verbs could appear in menus from All Files, Folders, Directories, and All System Objects. Knowing the dynamic verbs may or may not appear, and if they appear not necessarily in a predictable order, I will have a logical basis for trimming the context menus. (Randomly pruning the context menus is a recipe for disaster.) I'm doing this not just to make the context menus more pleasing to the eye but, in the first instance, because many are longer than the height of my screen. Not only do they take a long time to generate, the verb I'm after, Properties, is right down the bottom! :-)

Thanks again,

MilesAhead

  • Supporting Member
  • Joined in 2009
  • **
  • Posts: 6,670
    • View Profile
    • Miles Ahead Software
    • Donate to Member
Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus
« Reply #13 on: September 09, 2015, 05:42:21 PM »
I'm doing this not just to make the context menus more pleasing to the eye but, in the first instance, because many are longer than the height of my screen. Not only do they take a long time to generate, the verb I'm after, Properties, is right down the bottom! :-)

I have noticed this on my Laptop.  Especially with only 768 vertical pixels it fills up with junk fast.  Although in my case I was able to get it to fit by setting many programs to use  submenus.