After performing some Google-fu and searching Stack Overflow I've been unable to find a way to access the right click menu of an item and read data or select an item from it. I've looked up methods for SendMessage and PostMessage
What I've done so far:
This is an example of post here that would have been exactly what I want if it didn't use Qt and would work on an external application. Everything I've been able to find is about creating a right click menu when I just want to view an external application's right click menu.
I've tried getting the handle of the context menu using Spy++ but the menu just disappears as soon as I select the "Find Window" option in Spy++ (which is to be expected).
The only way I could think of doing this is using mouse_event to display the box but then I don't know where to go from there. I feel like this would also be very inefficient.
I'm working on some legacy code so I don't have a lot of choice in what I can use, if it's possible I'd like to not use libraries that aren't included in Visual Studio 2008.
What I'm trying to do:
I'm looking for a way to access the right click context menu in an external application and read the data in it and then select an item. I feel like this should be really simple but my research skills are subpar. If anyone can point me in the right direction I would really appreciate it.
Thank you for reading!
The only way you can get hold of a context menu is to make the application display it. It doesn't exist otherwise. (The other question you give as an example is regarding the Windows Shell menu which is designed to be useable)
A window gets sent WM_CONTEXTMENU when the user right clicks, so you could use SendMessage() to invoke the menu, or failing that just send a right click.
After a bit of googling, I think context menus have a classname of #32768, so you could use FindWindowEx to find a child window handle with the matching classname.
Once you have the window handle, you can use the MN_GETHMENU message to get hold of the menu handle.
Related
I want to log the messages of this menu using Spy++.
Usually, if I want to log the messages of a window, I would use Spy++ and drag the "Find Window" tool over it. But in this case, if I drag the tool over this menu, the menu disappears because I clicked outside it.
Is there any workaround to this?
A little more information:
What I want to achieve is finding out what messages are sent when I click the menu's items (they are buttons).
That particular menu in the first picture is created only when I click the button, and it has a different HWND every time I click it.
If I can't accomplish this in Spy++, can I do this using some other application similar to Spy++?
Actually I figured it out myself.
You can just log messages of the parent window with the logging options set to also log messages of child windows.
As the context menu for the desktop and explorer windows is disabled, I wanted to make a little something to bring back some functionality. My idea was to just list out things in a context menu (copy, paste, new, open with, etc) whenever a user right-clicks one of these windows, and then just simulate the appropriate event in the actual menu (file->new, edit->copy, etc). It wouldn't look perfectly pretty, but it would hopefully allow for the use of right-clicking.
The problem is that I cannot seem to get the actual menu. I opened My Documents and tried going down the child list towards SysListView32, calling GetMenuItemCount each time. Most returned -1, and the only other return value than that was 0.
How am I supposed to get a handle to the (file, edit, view...) menu?
If this isn't possible, is there a way I could simulate the user clicking something on the normal context menu, even if it's disabled?
Also, is there a way of making this work for the desktop? You can get the same type of thing if you view it in the explorer window, so I figured there might be a way.
I'm running Windows XP and any help is appreciated.
As per David Heffernan's comment,
As for your question, you are on the wrong track.
GetMenuItemCount needs an HMENU but you've been feeding it HWND.
That won't work. It also won't work from a different process.
You could possibly write a program that use the shell COM APIs
to show a context menu for a shell item. But your basic problem
is the bone-headed group policy. You really need to get that fixed.
Tell the IT guy that takes the decision that I said he was a fool
and was stopping you doing any useful work. ;-)
This led me onto the path of using the correct alternative method to achieve my goal.
I always been interested on how we can accomplish this (hide/show the main menu using the alt key), and now some applications do this very often. One that really please me is the visual studio 2010 with this plugin:
http://visualstudiogallery.msdn.microsoft.com/bdbcffca-32a6-4034-8e89-c31b86ad4813?SRC=VSIDE
(firefox also do this, but i think that is in a different way)
Can anyone explain me how this can be achieved or if you known of any sample project that demonstrate this please tell me.
(what i can see in some replies here in stack is that we have to destroy the menu when is to hide and create it when is to show?! but this seems a bit bad solution...)
Thanks
The SetMenu function lets you add/remove the menu from the window. It does not destroy the menu.
Note that most applications which have the dynamic menu hide/show behavior are not really showing a menu. They're showing a custom control that looks like a menu.
You might also take a look at MFC support for auto hiding menus. I used this technique and it worked really well.
in CMainFrame::OnCreate I did
m_wndMenuBar.ShowWindow(SW_HIDE);
which actually works fine in our project
I stumbled across a related pit fall that will show a hidden main frame without your consent:
Whenever the focus for a child window in an MDI application changes (e.g. due to right clicking in it), the function CMDIChildWnd::OnMDIActivate will be called, which in turn shows the main menu (even if it was removed or destroyed previously) of the MDI application.
This works basically by adding the saved main manu from the underlying's CMDIChildWnd m_hMenuShared variable.
A quick&dirty hack to prevent this, is setting m_hMenuShared to NULL (it's protected in CMDIChildWnd so this needs a custom derived child class of CMDIChildWnd) for all child frames.
I would like to prevent the context menu from being closed in my win32 c++ application. I want to prevent closing the submenu when user clicks on a submenu item. Which message do i have to implement/override?
Haven't done win32 dev in a while, however just random thoughts that come to my mind - maybe will be helpful:
1) maybe you could try to show the context menu again right after the item was clicked
2) or do it the complex way - find, then subclass the context menu window, then intercept WM_CLOSE/WM_DESTROY messages
Overall this seems to be a weird thing to want to implement. Maybe the menu is not the right UI element if you want to keep it on the screen after the selection was made. Maybe you need a modeless dialog instead?
Please see the following article.
I am currently writing a plugin for a third party application.
As the plugin framework does not provide any way to access the UI I am now trying to do this manually via the WinAPI.
More specifically, I want to add a custom menu item for my plugin in the "File" menu.
My first attempt using FindWindow to retrieve the handle of the main window and the using GetMenu was not successful, as GetMenu simply returned NULL.
My next step was to use EnumChildWindows and search for a child having the text "&File" (I really don't like this approach as it makes localization quite terrible). However, I only found out the handle of the menu item, but I need the corresponding HMENU to use AppendMenu then, don't I?
Simply casting does not work and results in an "Invalid menu handle".
Is it actually possible to achieve what I am trying? How?
Thanks for your ideas in advance!
It more than likely just isn't a HMENU. Custom menu implementations are common, the one Window provides is dated and inflexible. Compare to Windows Forms' MenuStrip for example.
Of course, that blows a gaping hole in your approach.