CODEWITHSUNDEEP
c#menucontextmenuwindows-shell
Craig
Craig

Reputation: 661

Add to shell context menu only in my app

In my .NET Framework 4 app, I display files, folders and other stuff that is not part of the file system. For files and folders, I managed to display the Windows Shell context menu for that item, thanks to this code on MSDN. (It still fails to display the Carbonite Shell Extension but I digress.)

My struggle is in adding my own submenu to the Shell context menu. All of my research alludes to so-called Shell Extensions, which, if I understand correctly, is a system-wide change. I only want to add to the Shell context menu when it is accessed from within my app.

Grasping at straws, admittedly, I tried to add the following in the above class' ShowContextMenu method, just after it calls QueryContextMenu:

var mii = new MENUITEMINFO();
mii.cbSize = Marshal.SizeOf(mii);
mii.fMask = MIIM.SUBMENU | MIIM.STRING | MIIM.FTYPE | MIIM.ID;
mii.fType = MFT.BYPOSITION;
mii.wID = 0;
mii.hSubMenu = subMenu.Handle;
mii.dwTypeData = "Test";
var success = InsertMenuItem(pMenu, 0, true, ref mii);

but with no "success". (subMenu is a System.Windows.Forms.ContextMenuStrip that I created earlier.)

My questions are:

  1. Am I correct that what I am attempting is distinct from creating a Shell Extension?

  2. Is this still considered to be dangerous activity from managed code, as per this post?

  3. How does one actually do this?

Upvotes: 4

Views: 1501

Answers (1)

Craig
Craig

Reputation: 661

OK, looks like it is possible to add custom menu items to the Windows Shell context menu, just in your app (no need to do anything that affects the entire Windows system). Below is what I did. Keep in mind that this answer should be taken in the context of the MSDN code first mentioned. Here's the link again:

ShellContextMenu class on MSDN

In that class, specifically, the method ShowContextMenu, is a call to QueryContextMenu, whose purpose I learned is to populate the menu with items--in this case, the appropriate Windows Shell menu items for the file/folder whose context menu is to be displayed. After that call, I added the following code to add a submenu and a separator:

var mii = new MENUITEMINFO();
mii.fMask = MIIM.SUBMENU | MIIM.STRING | MIIM.FTYPE | MIIM.ID | MIIM.STATE | MIIM.BITMAP;
mii.fState = MFS.ENABLED;
mii.fType = MFT.STRING;
mii.wID = 0;    // Application-defined value that identifies the menu item.
mii.hSubMenu = **subMenu**.Handle;
mii.dwTypeData = Program.ShortTitle;
mii.cch = mii.dwTypeData.Length;
var bmp = new System.Drawing.Icon(ac.Properties.NeutralResources.MyAppIcon, 16, 16).ToBitmap();
this.hMyAppSubmenuIcon = bmp.GetHbitmap();
mii.hbmpItem = this.hMyAppSubmenuIcon;
mii.cbSize = Marshal.SizeOf(typeof(MENUITEMINFO));
var success = InsertMenuItem(pMenu, 0, true, ref mii);

mii = new MENUITEMINFO();
mii.fMask = MIIM.FTYPE;
mii.fType = MFT.SEPARATOR;
mii.cbSize = Marshal.SizeOf(mii);
success = InsertMenuItem(pMenu, 1, true, ref mii);

subMenu is of type System.Windows.Forms.ContextMenu. In this way, the entire context menu is somewhat of a hybrid, consisting of both managed and unmanaged menu items. So far, I don't see a problem with this; it just means that handling the selection of the two types of menu items must be done differently, as described below...

After inserting the managed item(s) to the menu, the ShowContextMenu method calls TrackPopupMenu. For Shell menu items, the already-written class takes care of handling their selection. For my own menu items, I had to take extra steps because TrackPopupMenu is a Windows API function so it doesn't work very well with the managed submenu items' Click event. You can hook up Click event handlers to your submenu items but when they are selected from the Shell context menu, their Click event doesn't fire. I did still wire up their Click even because sometimes I just display my managed menu on its own.

To take action in response to the managed menu item selection from the Shell context menu, I used the return value of TrackPopupMenu, which is the resource ID of the menu item that was selected. That's where things got a little roundabout. When creating the managed context menu, each menu item has an index. You can use this with the Windows API function GetMenuItemID, which returns the resource ID of the menu item. I inherited from the managed ContextMenu class and encapsulated a Dictionary that helped me to map from this resource ID to the menu item, to be later used just after the call to TrackPopupMenu. For my purposes, that's all I needed in order to invoke the handler because in my app, I use a command pattern and I stored the command object in the menu item's Tag property when creating the menu. (Once the dictionary gave me the correct menu item, I was able to execute the corresponding handler by extracting the command object from the Tag).

This has been running fine for several days now. If anyone see holes, like unmanaged resources that I should have cleaned up, please mention.

Upvotes: 1

Related Questions