Messages

1

Post New Requests Here / Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus

« on: September 04, 2015, 02:00 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,

2

Post New Requests Here / Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus

« on: September 03, 2015, 06:44 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.

3

Post New Requests Here / Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus

« on: September 03, 2015, 02:53 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,

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.
             

4

Post New Requests Here / Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus

« on: September 02, 2015, 05:09 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.

5

Post New Requests Here / Re: [Request] Debugging Tool for Dynamic Verbs in Context Menus

« on: September 02, 2015, 05:02 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.

6

Post New Requests Here / [Request] Debugging Tool for Dynamic Verbs in Context Menus

« on: August 23, 2015, 04:23 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.



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.

7

ProcessTamer / Re: ProcessTamer - Error accessing registry

« on: October 04, 2007, 06:16 PM »

Here's a short log to illustrate the issue. It appears that ProcessTamer is querying the registry every second.

8

ProcessTamer / ProcessTamer - Error accessing registry

« on: October 01, 2007, 05:48 AM »

Have been using ProcessTamer for about three weeks now and think it is great. Very cool idea.

I'm currently using ProcessMonitor (SysInternals) to track an error I'm getting on my machine and just happened to notice that periodically the following appears.




.
.

Is this a problem or is it normal behaviour?

The full path is 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\Disable Performance Counters'.