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,

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,

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.
             

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.