C# Windows 'Open with >' Context Menu Behaviour

C# Windows 'Open With ' Context menu behaviour

The Open With command just passes the path of the file as the first argument to the application so all you need to do is

public static void Main(string[] args)
{
if(args[0] != null)
{
//args[0] contans a path to the file do whatever you need to do to display it
}
else
{
//Start normally
}
}

To automaticly put your program in the open with list you will need to add some reg keys in HKEY_CLASSES_ROOT\YOUR_EXT\. Here is a SO answer saying how to do it

Or you could just add it by hand to the open with list the normal way.

Open With... context menu, different label for executables of same name

While the above mentioned question seems to hint at the possibility to specify the FriendlyAppName as a string, my tests didn't come to the right results and Microsoft's documentation seems to indicate that it needs to be a lookup into a file resource.

Hence my current "solution" is to write to the HKCR\Local Settings\Software\Microsoft\Windows\Shell\MuiCache key and the associated value for my application as follows:

[Registry]
Root: HKCR; SubKey: "Local Settings\Software\Microsoft\Windows\Shell\MuiCache"; ValueData: "{#MyAppNameLong} Build {#MyAppVersion}"; Flags: uninsdeletevalue; ValueType: string; ValueName: "{app}\bin\{#MyAppExeName}.FriendlyAppName"

For now this works and I'm hoping that the Cache in the key name doesn't hint to this being rebuild out of the blue by windows...

C# - How to trigger the App in open with context menu properly

Finally, I found the reason. We need put the [STAThread] on the entry point.

See windows document STAThread

This attribute must be present on the entry point of any application that uses Windows Forms; if it is omitted, the Windows components might not work correctly. If the attribute is not present, the application uses the multithreaded apartment model, which is not supported for Windows Forms.

namespace test
{
class Program
{
[STAThread]
static void Main(string[] args)
{
FileInfo[] files = new FileInfo[1];
files[0] = new FileInfo(@"K:\qqq\tofu.png");
ShellContextMenu scm = new ShellContextMenu();
scm.ShowContextMenu(files, Cursor.Position);
}
}
.
.
.
}

C# Programmatically Open on Context Menu a file

Thank you for helping me.

I finally solved by seeking the 'Open' menu command from the registory key.

Here is the code to seek.

shellComand takes : New, Open, Edit. Below code seek the Open menu context command.

static string SeekExtensionBehaviour(string path, string shellComand)
{
string extension = System.IO.Path.GetExtension(path);

string command = "not found";

if (string.IsNullOrWhiteSpace(extension)) return command;

using (RegistryKey keyExt = Registry.ClassesRoot.OpenSubKey(extension))
{
if (keyExt == null) return command;

var keyRealExt = keyExt.GetValue("");

if (string.IsNullOrEmpty(keyRealExt.ToString())) return command;

using (RegistryKey keyReal = Registry.ClassesRoot.OpenSubKey(keyRealExt.ToString()))
{
if (keyReal == null) return command;

string keycommandPath = string.Format(@"shell\{0}\command", shellComand); // New, Open or Edit

using (RegistryKey keyCommand = keyReal.OpenSubKey(keycommandPath))
{
command = keyCommand.GetValue("").ToString();
}
}
}

return command; // "C:\Program Files (x86)\Microsoft Office\Root\Office16\WINWORD.EXE" /n "%1" /o "%u"
}

string command = SeekExtensionBehaviour("override shell command.dot", "Open");

Please replace the variable for 'command' paramters as it has %1 and %u. %1 is the path to oepn the file.

Thank you very much guys!

All WPF context menus do not seem to handle highlighting items properly when a modifier key is held down

MenuItem sets an internal flag when a key is pressed that stops mouse events from being registered temporarily, regardless of if it is actually a key that performs navigation. This reflects the behavior that I see, which is that the selection stutters when I hold down any key, not only modifiers. https://referencesource.microsoft.com/#PresentationFramework/src/Framework/System/windows/Controls/MenuItem.cs,2049

Since it's private there is no proper way to fix this. However if it is critical you can add a KeyDown handler for all your MenuItems and then change it with reflection

var menu = sender as MenuItem;
if (menu != null)
{
var parent = ItemsControl.ItemsControlFromItemContainer(menu);
MethodInfo setBoolField = menu.GetType().GetMethod("SetBoolField",
BindingFlags.NonPublic | BindingFlags.Static);
setBoolField.Invoke(this, new object[] { parent, 0x04, false });
}

If you want you can first check if the key was a navigation key to retain the desired behavior.

I would personally consider this a bug in WPF.

How to Snoop a ContextMenu?

Whenever user performs any action outside of an opened ContextMenu will get closed. This is default behaviour of the ContextMenu, But still Snoop provides all the informations about the ContextMenu and it's MenuItems in the VisualTreeView of the Snoop window on Left side. If you want to snoop a specift ContextMenuItem

  • Attach your application with the Snoop
  • Press Shift+Ctrl and mouse over to the ContextMenuItem you want to snoop which shows a Red border. Also the same control will be selected in the Treeview of the Snoop window


Related Topics



Leave a reply



Submit