[RESOLVED] Modify right-click context menu in standard controls

[fafalone]

Looks very awesome. I love how everyone each has their own subclassing methods, which is making things very difficult to follow (i subclass to 1 wndproc and handle every message there, instead of forwarding back to another procedure). Working things out now, if you get back to this thread before I update this post, is there any way you could elaborate a bit on the code flow? I'm not as smart as I used to be and am having just a little trouble figuring out the sequence of events etc. (modifying a copy/paste only has limited value, i want to completely understand things, for both knowledges sake and integrating this with all the other extensive subclass code--since supporting unicode and some other things neccessitated using a pure-api control made with createwindowex)

Edit, nevermind. Got it working! Thanks very much for the help. Also, I'm on Win7 x64... so if it works on XP too, I'd imagine it should work on Vista.

[LaVolpe]

is there any way you could elaborate a bit on the code flow?

1) Wait for a WM_ContextMenu message
2) When received, start a hook to look for newly created windows
3) Forward the WM_ContextMenu message
4) In hook procedure, look for #32768 creation and keep monitoring its messages until the menu is created
5) When menu created, append/modify menu items, stop hook
6) After WM_ContextMenu finishes being forwarded, stop hook just in case it wasn't stopped earlier
7) When user selects a menu item, a message is forwarded to the textbox

Limitations: This method should work well for menus created via the TrackPopupMenu API. Many, if not most, context menus are done this way. If the desired menu isn't part of a #32768 window class, then the above won't work for that particular menu. For example, standard menus (at top of window) and system menus generally won't use that method.

P.S. I rarely handle any subclassing/hooking procedures within the actual procedure and NEVER callback directly to a form. Did so here just because it was a 'simple' workup. Personally, I use classes. The procedures make calls to the classes and the classes do the work or forward the messages via Public Events or via Implements. Each subclassed window has its own class. Each hook type has its own class. The idea is that your subclass/hook procedure remains generic, just a repeater. This allows each class, or form via Implements, to customize responses to the messages.