Windows Explorer add-ons - windows-explorer

How do tools like SVN and Git attach themselves to Windows Explorer, such that they add options to the right-click menu as well as adding the tick/exclamation mark based on whether a file has been edited?
(I'm not after Git or SVN-specific information - I just used them as examples)

What you want is called Shell Extensions, are in-process COM objects which extends the abilities of Windows operating system.
(source: csscript.net)
you can see these links
The Complete Idiot's Guide to Writing Shell Extensions - Index
Registering Shell Extensions
Bye.

Explorer allows DLLs to register as shell extensions. A shell extension can provide context menu items, icon overlays and numerous other features. It does this by exposing certain COM interfaces which Explorer calls e.g. prior to displaying a menu or icon. Here's the MSDN home page for shell extensibility -- though oddly enough the stuff about context menus and icon overlays no longer seems to be there -- you may have to try the offline SDK under Win32 and COM Development | User Interface | Windows User Experience | Windows Shell | Shell Developer's Guide | Integration of Applications into the Shell.

Depending on the shell extension you want, they can be QUITE complex to implement. I don't know what you're looking for, to quickly write a nice extension, or to get in to the nitty-gritty and learn all the hands-on of it all.
If you aren't as concerned with the how, and just have some ideas you want to implement, check out this library for writing shell extensions...
EZShellExtensions MFC
EZShellExtensions.NET
There are a lot of different types:
- Context Menus
- Property Pages
- Icon Handlers
and many more...
They also have another library for writing namespace extensions (things that show up in the tree pane of Windows Explorer).

Related

How can I register my app for “Open with” (File Type associations) in context menu on Windows 11?

We are trying to update our application to be available by default when clicking "Open With" in Context Menu on Windows 11 for some file types after it was installed.
The doumentation is really poor at the moment. The only place where I found this is mentioned is:
https://blogs.windows.com/windowsdeveloper/2021/07/19/extending-the-context-menu-and-share-dialog-in-windows-11/
In this blog, in Context Menu Best Practices chapter they wrote this phrase without giving an actual example:
---“Universal openers,” like technical text editors, should register to handle * so they will always be offered as an “Open with” option. They should also explicitly register for any filetypes they are optimized to handle.---
Does anyone implemented this or found some better documentation?

How to create an application for windows explorer contextual menu?

I do not know how exactly this procedure is called but I want to create an application that lives only on the contextual menu of Windows Explorer (left click on explorer), something like http://www.extrabit.com/copyfilenames/ but I want to create another type of application. Where do I start? I am familiar with C++, C#, Visual Studio...
What you are looking is called Shell Extensions, for more info check these MSDN entries about this topic.
Working with Shell Extensions
Creating Shell Extensions with Shell Instance Objects
Creating Shell Extension Handlers
Registering Shell Extension Handlers
Walkthrough: Creating a Shell Extension

WinAPI: Call context menu entry provided by shell extension

The software Dropbox provides an shell extension which adds context menu items to all files in a specific folder. One of these generates a public link to view the selected file.
In a C# tool I want to call this entry without any user interaction. I want to achieve the same behavior as if the user clicked on the context menu item of a selected file.
I know that the shell extension is provided by a DLL, is it possible to make a call to this DLL to achieve the expected behavior?
Shell extensions implement IContextMenu and it is possible to execute menu commands without showing a menu (See this blog post for details about "hosting" IContextMenu)
Once you have the menu, you would call IContextMenu::GetCommandString and look for a specific verb, if Dropbox does not have a somewhat unique verb, you are going to have to do something hacky, either match by menu text alone, or call the Dropbox shell extension dll directly (DllGetClassObject export) and fake everything (Pretend to be COM and shell) or if you know the CLSID, you can at least get help from COM and just do the shell part.
There is a freeware tool called runmenu that allows you to play with shell menus/IContextMenu (I'm sure you can find a copy somewhere)

Main Window in Resource Script (.rc)

I'm not exactly sure what you can (or should) do with *.rc files. Most Win32 example code, including Visual Studio templates, creates the main window programmatically in WinMain. I could create a dialog in the resource script and just show it in WinMain, but I'm not sure if that's the best idea, since dialogs are treated differently than windows. Is there a way to put controls in the main window from a resource script, or should I just create it as a dialog?
The only Win32 API which places controls on a Window are the CreateDialog[Indirect][Ex] family of functions.
The practice of creating a dialog was the root window of the application has been common since 16-bit Windows and even today's 64-bit Windows maintains compatibility with that practice.

Customizing Windows Right-Click menus with multiple levels

I understand the process needed to customize a right click menu going through the regedit etc. However I need to the ability to go multiple levels such as in applications like WinZip. Here's a picture for clarification of what I need
alt text http://img14.imageshack.us/img14/9658/multiplemenus.jpg
You need to write a Shell Extension; there is a guide for writing one in managed code (C#) here. It will involve doing a bunch of interop and implementing COM interfaces that the windows shell will consume, namely IShellExtInit and IContextMenu.
However, one could argue that writing a Shell Extension in managed code is not advisable; it will force windows explorer to load the CLR, (or any app that uses the standard windows 'Open File' dialog) - native code (C++) would be a better choice for this.

Resources