Freigeben über

Property Handler Decisions and Preparation

  • Artikel

Viewed as a data flow component, a property handler has a single file stream input and outputs a one or more properties.  Unfortunately, writing one requires making many decisions before you even set eyes on the code.  Let's look at a few of these preparations.

First, pick a file type.  You'll be writing a property handler for this file type.

Now decide which properties you want to store.  Properties generally fall into a few categories.  Take a moment to consider which of the following you want to support:

  • System defined properties (e.g. System.Author)
  • Properties you define for your filetype (e.g. MyCompany.MyApp.MyProperty)
  • Properties other people define and want to set on your file (e.g. SomeoneElse.Other.Property, aka "open metadata")

Next, decide where in the file you'll be storing the properties.  Hopefully the file's format allows for this already.  If it doesn't, you'll have to collaborate with other users of this file format to accomodate these properties.  Here are a few storage options:

  • Compute the property from other data in the file (e.g. System.Document.WordCount)
  • Read the property from a specific location in the file (e.g. the EXIF header in certain image formats)
  • Read the property from a dynamic storage structure (e.g. suitable for storing SomeoneElse.Other.Property)

And let's not forget deciding which of your properties will be viewable, editable, searchable, etc.  Better start taking notes if you haven't already!

Once you know where to place your properties, you get to decide how to format them in your file.  Will you turn them into strings?  Or would a binary format be better?  Maybe you'll want to store some properties directly in the file format and others into a special dumping ground for open metadata.

Also quite important is choosing which API you will use to write to the file format.  Hopefully it supports stream inputs.  If it doesn't you'll have to flag your handler as "legacy".  Typically you'll end up writing a small layer mapping propert keys and values to whatever the format-specific API uses.

There is one easy decision in this mix.  Choose your programming language from the following list: C++, C.  Regrettably, shell extensions cannot use the CLR, so you may not use C# or any other .NET language.

As you can see, there are a lot of little decisions you get to make when writing a property handler.  There are undoubtedly more that I've missed, but you'll stumble upon those as you prepare your handler.  Additionally, there are many little options and flags you can use to tweak the way your property handler works and to accomplish more advanced tasks.  I am skipping those for now in favor of presenting them as a list later.

-Ben Karas

Comments

  • Anonymous
    January 30, 2007
    It would be nice if shell extensions could be written in CLR some day... On the bright side, it looks like preview handlers can be written in CLR, since they're out of proc:http://msdn.microsoft.com/msdnmag/issues/07/01/PreviewHandlers/default.aspx
  • Anonymous
    January 30, 2007
    Yup.  As Raymond clarified, it's in-process handlers that may not use the CLR.  Property handlers are loaded in-process (in explorer and in the search indexer), so the handler must use native code.  Of course, if you really really wanted to you could write your own IPC to a managed process, but that's a lot of work and adds overhead.  My personal take is that property handlers should be entirely native since there's no overhead.
  • Anonymous
    February 16, 2007
    I want to expand on your "store some properties directly in the file format and others into a special dumping ground for open metadata" statement.  Say I want to handle all ".myf" files which are a binary format that I know how to read, are you saying that I can actually store the metadata (properties) for .myf files in an associated XML file, for example a file.myf.xml file located in the same directory as the .myf file?  I am actually trying to do this now for a binary file format that doesn't use COM structured storage (so no IInitializeWithStream, right?)