Managed Preview Handlers

January 29, 2009

one comment

To set context, a preview handler in Windows Vista and/or Outlook 2007 is a component that provides a preview window for a specific file type (or set of file types).  For example, the default preview handler for .jpg files will display a preview of the image in the Windows Explorer or Outlook preview pane:


I’ve always had the impression that writing a shell preview handler was a daunting task involving lots of native code implementing obscure COM interfaces.  I’ve also been sure that the managed interop story was very sad, for the following simple (and convincing) reason: Assume that all preview handlers ran inside the explorer.exe (or outlook.exe) process.  What if preview handler A was built against CLR v1.1 and preview handler B was built against CLR v2.0?  Well, if handler B was loaded first, CLR 2.0 would be loaded into the process and then handler A would happily use it – after all, CLR 2.0 is backwards compatible with CLR 1.1.  However, if handler A was loaded first, CLR 1.1 would be loaded into the process, and handler B would not be able to run at all – because there is just one version of the CLR that can be loaded into a given process.  (This last remark will cease to be true as of CLR 4.0, but preview handlers have been there for a couple of years now.)

However, this was a myth.  I will be the first to admit that I didn’t do my homework.  Preview handlers always run out of process, by default in the surrogate host called Prevhost.exe (these handlers won’t be compatible with Outlook 2007 on Windows XP).  How is this any better than running all preview handlers in the Explorer.exe process?

Well, it’s possible to specify that your preview handler should be launched in a separate instance of Prevhost.exe instead of sharing the default one.  This effectively gives you the tools to separate managed preview handlers into different processes, e.g. according to the version of the CLR they were built against.

Still, writing a managed preview handler wouldn’t be trivial – there are several COM interfaces to implement, and some registry keys to set so that your handler is recognized by the shell.

Fortunately, Stephen Toub’s amazing article from MSDN Magazine titled “Writing Your Own Preview Handlers” provides a managed framework for developing preview handlers.  Writing a managed preview handler using that framework is as easy as:

  1. Deriving a class from StreamBasedPreviewHandler or FileBasedPreviewHandler
  2. Implementing the CreatePreviewHandlerControl method
  3. Deriving a class from StreamBasedPreviewHandlerControl or FileBasedPreviewHandlerControl

The rest is the details of drawing a Windows Forms representation of your file type (and of course you can integrate WPF inside using the ElementHost wrapper control).

If you never got the chance to experiment with the Windows Shell, writing a managed preview handler is an incredibly easy opportunity to get started.  If there’s any file type that you wished there was a preview handler for, you can finally write one yourself!

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


one comment

  1. Daniel MothJanuary 29, 2009 ב 10:00 PM

    Ignoring the risk of looking like a spammer, FYI here is a screencast *showing* the managed preview handler framework in action: