Welcome to shell: revealed Sign in | Join | Help
in Search

Shell Blog

Shell Namespace Extension: Enabling Deep Search

Overview

From my past posts about implementing your own Shell Namespace, there have been some great questions posted by readers.  Many of these stem from the fact that the Namespace example is fairly simple in that it does not implement all of the behavior that is possible in Explorer.  This was done to focus on the core steps in getting a working Namespace implemented.  Yet, there are a few extra steps you can take that don’t require too much more coding on your part to add more useful features.  One question in particular that comes up quite often is how to enable deep searching in your Namespace.

You will notice from the existing Namespace example that if you enter a search term in the search box in Explorer, the search only filters items that are currently in the view.  It does not search into the folders.  In the below images, we try to search for “Two” in the search box which only results in 1 item.  Thus, the sub folders were not included.

Filter Search

Filter Results - shallow

What does a Namespace implementer have to do in order to include sub folders in their namespace search results?  This is actually fairly simple.

Implementing IShellFolderViewCB and IFolderViewSettings

In our previous code, we did not implement an IShellFolderViewCB for our Namespace.  This allows your Namespace to be notified of events associated with the view.  An implementation of IShellFolderViewCB can be specified in your call to SHCreateShellFolderView.  This is optional and previously we were just passing NULL for this.   We need to create a class that implements IShellFolderViewCB as well as IFolderViewSettings.  For our IFolderViewSettings implementation, we only need to provide a handler for the GetFolderFlags method.  It is through this method that we notify the Shell that we want to perform deep searches within our Namespace.

IFACEMETHODIMP CFolderViewCB::GetFolderFlags(__out FOLDERFLAGS *pfolderMask, __out FOLDERFLAGS *pfolderFlags)

{

    if (pfolderMask)

    {

        *pfolderMask = FWF_USESEARCHFOLDER;

    }

    if (pfolderFlags)

    {

        *pfolderFlags = FWF_USESEARCHFOLDER;

    }

   

    return S_OK;

} 

As you can see from the above implementation of GetFolderFlags, we only care to notify the Shell of the FWF_USESEARCHFOLDER flag.  This tells the Shell that our Namespace should use the Search Folder for performing stacking and searching.  You could also specify other flags to modify the appearance and behavior of your namespace.

The modified code for this sample is linked below.  You will notice that the implementation of IShellFolderViewCB and IFolderViewSettings is rather sparse – most methods just return E_NOTIMPL as we are not using them here.   You can implement these yourself if you see the need to extend your code.
Now that we have notified the Shell to use the Search Folder, we can perform deep searches within our Namespace.  When we perform the same search we did previously, we now get the following results:

deep search

This Namespace simply generates 10 virtual items to a default depth of 5.  The Search enumerates the contents of the Namespace to that depth.  It should also be called out that we had to implement our namespace's ParseDisplayName method in order for our namespace to function in the Search folder.

*Please note that the method described here only works with the default shell view (Defview).  It is not supported for custom IShellView implementations.

Building the FolderView SDK Sample

  1. To build the FolderViewImpl sample, be sure to download and install the Windows SDK.
  2. Download the modified FolderView SDK sample
  3. Launch FolderViewImpl.sln in Visual Studio (The solution file is for Visual Studio 2008)
  4. Open the properties for the project
  5. Add a path to the SDK includes to the C/C++ - General page
  6. Add a path to the SDK libs to the Linker – General page
  7. Build

Installing the FolderView SDK Sample

  1. Once you have built the sample, copy the FolderViewImpl.dll and FolderViewImpl.propdesc to the same directory
  2. From an elevated cmd window, regsvr32 FolderViewImpl.dll
  3. Restart explorer
  4. Open explorer to Computer
  5. There should be a list item named “FolderView SDK Sample”

Published Monday, March 03, 2008 3:50 PM by chrdavis

Comments

 

blackwell said:

Chris, with all due respect, and knowing that this probably isn't the place, and you are possibly the wrong addressee, allow me to express what I perceive as an extremely unfortunate situation:

I am not a Microsoft system programming specialist. I am an application developer. I don't know MFC, COM, etc. by heart. I can find my way around standard C, C++, Java, Python. But I cannot for the life of me understand the twists and turns and indirections that Microsoft forces upon me, nor the massive lack of documentation and example for something like showing (shell) item and background context menus.

An ideal example for showing shell context menus:

CStringArray files;

[...fill files array...]

SHShowContextMenu(someWindowHandle, files, flags);

Simple, isn't it? Add a few more lines for the message handling, I'd be fine with that.

Now let's let at what is actually required:

http://www.codeproject.com/KB/shell/shellcontextmenu.aspx

This (partly broken) project demonstrates showing the (item) shell context menu - in ca. 380 lines of code (I didn't count a few comfort methods) of relatively loaded C++ code using COM - and it doesn't even do it correctly, despite it's goal to provide a complete, ready to use drop in solution for this.

Is this a symptom of too much complexity, too many steps required, too many strings attached? I believe so.

How do you developers at Microsoft consider COM?

Do you think it is simple?

Do you think it is acceptable to require application developers to deal with the complexities of COM programming these days, given all the time pressure that software developers must endure?

Does Microsoft have a strategy to move away from it and to replace it with something simpler?

Has COM given us anything that couldn't have been achieved with plain c/c++ APIs, but a truckload of complexity that heavily distracts us from our main goal, to develop solutions for specific customer problems?

I have come up with a simple metric to see if something is too complex or too indirect:

Consider the ideal, least effort solution (join a Blog community, for example), make it more general if you see other cases, then count the number of indirections (be it clicking buttons, scrolling through pages, clicking the mouse here and there, checking check boxes, etc. pp.). If the real life case requires more clicks/indirections/mouse movemens/data entries than your generalized, solution driven, yet slightly generalized solution, chances are high that there are too many indirections involved.

Given this metric, how many indrections are necessary to solve my problem of showing the shell (item) context menu? And what is the justification for these indirections? Can they be justified? These days, where fully integrated, complete shell namespace extensions should ideally be implemented in a matter of days, by developers not fluent with COM?

Sorry, I am venting, babbling and I am horribly frustrated after several days of chasing these shell (item and background) context menu solutions. (For which we have filed a support request with Microsoft, asking for working examples for both, hopefully the request can be satisfied by them.)

Bye bye

June 11, 2008 5:49 PM
Anonymous comments are disabled
Powered by Community Server, by Telligent Systems © 2006 Microsoft Corporation. All rights reserved. Terms of Use | Trademarks | Privacy Statement.