IPropertyStore vs. IFilter

Mar 9, 2007 at 7:30 PM
Jerry/James,

I hope you're not sick of me yet ;) Your replies have been really useful and I appreciate your quick and thorough responses.

RegNamespace includes coclasses that implement both IPropertyStore and IFilter. The Windows SDK 6.0 documentation for property handlers implies that normally you would implement either IPropertyStore or IFilter and gives a comparison chart for the two approaches.

Can you comment on how/why you are using both interfaces in your sample?

I should mention that the context for my question is deciding the best approach to implement searchable properties for files with a certain file extension. The files are a binary format that doesn't use structured storage (no IStream). This is a separate property/search/index project from my other posts to this forum.

Thanks!
Coordinator
Mar 10, 2007 at 4:57 AM
Matt,

Can you send me the link to the SDK documentation you are referring to. It will be easier to answeer this question if I have that context.

Thanks.

-Jerry
Mar 10, 2007 at 7:13 AM
Sure, it's at:

http://msdn2.microsoft.com/en-us/library/aa969363.aspx

Search for "Full-Text Contents", that's the section I'm referring to.

Thanks again,
-Matt
Coordinator
Mar 11, 2007 at 4:05 AM
Matt-

I read the documentation you referred to and I did not infer from it that IPropertyStore and IFilter are mutually exclusive. In fact I think the opposite is true. Here is the excerpt I think is relevant:

"The table below summarizes the benefits of each method for use in determining whether you should add the additional support for IFilter to provide full-text content."

I read this as saying: "Implement a property handler, and decide whether or not you also need an IFilter based on the complexity of your file contents (PKEY_Search_Contents).

Even though RegNamespace implements IPropertyStoreFactory/IPropertyStore, there really is no "property handler" for the items in the registry data source. Property handlers are associated with specific file types (eg. .recipe in the sample). The reason I implement these two property interfaces is because that is the preferred way for Explorer to get properties from the data source (IShellFolder). In previous versions of Windows, Explorer would use IShellFolder2::GetDetailsEx to retrieve property values. In Vista, it first will attempt to get an IPropertyStoreFactory from the data source. If you do not provide the factory, Explorer will create a delegate property store for your items and use GetDetailsEx to retrieve the properties.

So, because there is no property handler for the items in my data source, I have to implement an IFilter to expose the properties to Windows Desktop Search.

From the brief description you have provided of what you are trying to do, I'd say a property handler is well suited to your needs.

You can read additional info on the property system from Ben Karas' blog. Ben was one of the major contributors to the property system implementation.

Hope this helps.

-Jerry

Mar 12, 2007 at 8:21 PM
Hey Jerry-

So the "pseudo" property handler for items in your namespace is mostly just used by Explorer when displaying a view of items in your NSE, and it is actually your IFilter implementation which makes everything available for Windows Desktop Search? I see that... and also that IFilter also uses the IPropertyStore of the IShellItem passed in to get to some of the properties. I think that it was that last part that made me think you were using a property handler to expose items in your NSE to WDS but I see now that that is not the case.

I actually have some items that have a well-known file extension (and thus can be exposed to WDS w/ a property handler) and others that only exist as part of an NSE (and thus require an IFilter and/or protocol handler). In the 2nd case the IFilter/protocol handler can make use of an IPropertyStoreFactory/IPropertyStore to get at the properties for items in my NSE if I handle the those interfaces in my IShellFolder::BindTo*** call, but the IPropertyStore is not what actually exposes items in my NSE to WDS.

Thanks for your replies!
Coordinator
Mar 12, 2007 at 10:14 PM
Matt-

That's correct. Having the protocol handler/IFilter use the IPropertyStore interface was a design decision. I wanted to keep the Registry API calls abstracted in one place, rather than having the shell data source make registry calls and then having to essentially duplicate that code in the PH/IFilter. There is no rule that the PH/IFilter must bind to shell folder objects to do the data collection.

-Jerry
Jan 3, 2009 at 5:50 AM
Matt, Jerry -

Hopefully you guys are still monitoring this thread...  I've got a project where I'm building an IFilter for a file format based on the Microsoft Exchange journaling feature which, in turn, is based on the .eml file format.  So I register a new file extension (.jeml) and created an IFilter for it.  The filter emits a series of properties specific to the journal envelope and then feeds the rest of the document through the standard .eml IFilter (mimefilt.dll).  Everything seems to run just fine when I test with FiltDump.exe.  But getting the filter to run in the context of Explorer.exe or general desktop indexing seems to be an issue.

As far as I can tell, I've got all the proper registry entries, but the system never loads my filter.

For standard indexing for WDS, I don't have to implement IPropertyStore or create a separate property handler if I've got the fill IFilter interface implemented, do I.  What's the point of IFilter::GetValue, if I still have to implement the other interface?

Any clarification you can lend here would be much appreciated.  I feel like I'm so close to getting this thing up and running, but I'm missing one tiny bit...

Thanks.

J