DonationCoder.com Software > Post New Requests Here
[Request] Debugging Tool for Dynamic Verbs in Context Menus
gr3gw:
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:
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:
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,[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:
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:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version