Windows Explorer add-ons

views:

202

answers:

Windows Explorer add-ons

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)

+1 A:

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.

itowlson 2009-10-13 03:58:57

+3 A:

RRUZ 2009-10-13 04:00:10

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).

eidylon 2009-10-13 04:39:11

you're linking to the .NET edition of that framework. Do never, ever use that! Never, ever write a shell extension in .NET. Here's why:http://blogs.msdn.com/oldnewthing/archive/2006/12/18/1317290.aspx

Stefan 2009-10-13 13:14:35

Interesting point. Hadn't thought of that. I guess though this may or may not actually be an issue depending on your target audience. If you're writing for a well-controlled audience (e.g. how intranet sites can target JUST IE, and ignore other browsers) it may not be an issue, but for public release it's a good point to take under consideration. Updated my answer to include the MFC version.

eidylon 2009-10-13 15:27:40

It's not an issue of IE vs. other browsers. The problem is that every app that uses plugins can break. Imagine a native app that uses COM plugins, and one of those COM plugins is written in .NET. If the app used a file-open/save dialog before it needs to load the plugin, that plugin can fail to load because another .NET runtime has already been loaded due to that bad shell extension.Actually, it's not even needed to use a file-open/save dialog: even some often used 'normal' shell functions like SHGetFileInfo() will do.And yes: I have an app that breaks if such shell extensions are installed

Stefan 2009-10-15 20:33:00

Yes, no; I understand what you're saying... the IE thing was just an example, of how you sometimes needn't worry about this kind of situation, depending on your application. For example, in many banking environments, the workstations are HIGHLY, HIGHLY controlled, and nothing goes on those systems which hasn't been deeply and thoroughly tested. If you're in one of those environments, things are in some ways, a little easier. For the general public though, yes - these issues are definitely something to consider.

eidylon 2009-10-15 21:28:50

ansaurus

tags:

views:

answers:

Windows Explorer add-ons

related questions