3

We've implemented a shell property handler for a custom file format, with some standard properties and some custom. When we browse our files in Explorer our properties display nicely, but when our files appear in search results they don't. It seems that Explorer isn't querying our property handler when it displays search results.

My question is this: When Explorer displays an item in search results, where does it look for the item's properties? Does it query the appropriate handler, or does it look somewhere in some kind of search cache?

If it queries the handler then I'll investigate why our handler isn't called. (Maybe it's a registration fault.) If it looks in a search cache then I'll investigate why our files aren't indexed properly.

A secondary question: Is the search results pane restricted to a limited subset of the standard properties? In other words, should we just give up trying to display interesting properties here?

Some observations:

  • Our file format is just .msg (Outlook email message) renamed to .msga. Our handler knows how to read the .msg file format.
  • Property values display correctly in Browse mode.
  • They don't display in Search mode.
  • Property values are displayed correctly in Explorer's details pane, in either mode.
  • Some standard properties display OK in the search results, but not others, and no custom properties do. For example, these all display OK but are not served by our handler: System.ItemName, System.ItemUrl, System.Size, System.DateCreated. These are available in our handler but do not display: System.Title, System.Message.FromAddress, System.Message.DateSent.
  • Explorer is clearly reading our HKCR\<progid> registry key, because the display adapts as we edit ContentViewModeForSearch etc.
  • Our .msga file type is listed in Control Panel as an indexed file type, and our files are in an indexed directory. And I rebuilt the entire index this morning.
  • We haven't implemented a filter. Control Panel says that it's using "Office Outlook MSG IFilter" for .msga. (I don't know how it figured this out - maybe I copied a registry setting early in the project, or maybe Windows inferred it because we use Outlook for preview.)
  • Our handler implements IPropertyStore but its methods seem never to be called. (We've implemented some logging, to a file that the search indexer should have access to, but we can't be sure about that.)
  • Event Viewer shows gatherer error 3036 during indexing: "The content source <csc://{S-1-5-21-2153095834-1917727522-598830505-500}/> cannot be accessed." I think that SID is my user account, and so I wonder whether it's trying to index something to which it doesn't have privileges.
Ciaran Keating
  • 2,793
  • 21
  • 19
  • What the interfaces your extension implements except the IPropertyStore (IPersistStream, IParentAndItem, IPersistFile, IInitializeWithStream, IInitializeWithItem, IInitializeWithFile)? – Denis Anisimov Mar 23 '16 at 07:24
  • It implements IInitializeWithFile, IInitializeWithStream, IInitializeWithItem, IPropertyStore, IPropertyStoreCapabilities, IQueryInfo, IPersistFile (only GetClassID) and IExtractIcon. It doesn't implement IPropertySetStorage because we didn't see a need for it, but maybe it is relevant for search results...? – Ciaran Keating Mar 24 '16 at 05:03
  • In my case on some machines the search displays custom properties OK, while on others it does not display them. – Alex Che Nov 08 '17 at 08:48
  • @CiaranKeating I was just wondering if you got solution to your problem? I am also facing similar issue where I am unable to get search results on any of the custom properties that my property handler manages. – Saket Sharad Jun 09 '20 at 05:38
  • @SaketSharad I don't remember much, but yes I think we got search working. Looking through the code today, I think the key was to implement IFilter. In IFilter::Init you have to return the list of properties that your filter supports, and then the shell will call your implementation of IFilter::GetValue(PROPVARIANT**) to get the property values. – Ciaran Keating Jun 16 '20 at 10:52

0 Answers0