I’ve been hoping that someday I’d actually have a short post to make on my blog about something Windows Desktop Search (WDS) related… But today isn’t that day…

 

We’ve been hearing some requests that users would like to add new locations to the “All Locations” list in WDS.  Maybe something like this:

 

 

So that when you type in a query and select this added location you get navigated to a set of web search results like this:

 

 

And to be honest the real request we heard was for info about adding new desktop search locations but since we support the adding of both desktop and web search locations to the list I thought I’d unofficially tell you how to add both.  As usual this isn’t an officially supported feature and is likely to change in the future.  But when it does change we’ll most likely have a UI for adding these things but for now you’ll have to add them manually via the registry.  So as a further disclaimer, be comfortable with modifying your registry before making any of these changes.  I’d also recommend you make a backup of your registry settings before making any modifications to them.

 

 

Adding “MSN Music” to your locations list…

 

You’ll want to open RegEdit and navigate “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSN Apps\DS\Views\Locations”.  Under that key you’ll notice a list of sub-keys for each location in the list:

 

 

As you can from the screenshot I’ve already added a new sub-key called Music for the MSN Music location displayed in my “All Locations” list above.  To add this same location to your list just add a Music sub-key under Locations and add the values you see in the screenshot.  Reboot your machine (or restart Explorer.exe) for the changes to take effect and the next time you launch a WDS results window your “All Locations” list should look just like mine.  Well almost like mine.  Yours won’t have a separator between “MSN Music” and “Outlook Express”.  To get a separator you’ll need to modify the OE sub-key as well:

 

 

Change your OE keys Separator value from a 0 to 1.  This should add the separator to your list after another reboot.

 

 

Understanding the “Locations” registry values…

 

So now I’ll drill into the details of what these seemingly random registry values mean and how you can use them to build a wide range of ready to use filters.  As you’ve noticed we currently support two types of locations, Desktop Search and Web Search.  The registry values you need to fill out are largely dependant upon the type of location you want.  But there are a few common values used to control the display of the location in the list so let me talk about those first:

 

• Title:  Display name of the location in the UI.
• Icon:  Resource info for the Icon to show next to the location.  “msnlExtRes.dll,-164” will show the globe with a magnifying glass icon but you should be able to assign any icon you want.  The format of this string is expected to be “<module>,<index>”.
• Position:  The locations order within the list.  It’s super important that the value of Position be unique and sequential for each location starting from 0.  So for the 6 entries in the screenshot their Position values are from 0 – 5.
• Indent:  The amount of indention if any to apply to the location.  This is used to represent a tree like structure within the list and can contain a value of 0 – 3.  A value of 0 means it’s a root location, 1 means it’s a child location, 2 means it’s a child of a child location, etc.
• Separator:  Inserts a separator line into the list immediately after the location.  A value of 1 means the location is followed by a separator and a value 0 means it isn’t.  Note that you can temporarily hide locations (see Visible) so we’ll try to be smart about automatically rolling up the separators for hidden locations to the next visible one in the list.
• Visible:  Temporarily removes the location from the list if set to a value of 0.  In hind site I wish we would have called this value Hide because its default value is 1 if it’s missing.  So its only purpose is to remove a location from the list.
• Type:  Determines the type of search performed when the location is selected within the UI.  A value of 0 means Desktop Search and a value of 1 means Web Search.

 

As you’ve probably figured out the locations list is built by simply walking the sub-keys of “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSN Apps\DS\Views\Locations” on first use.  So to begin with you’ll need to add a uniquely named sub-key to this hive and fill out the common values listed above.  If you’re adding a Web Search location you’ll need to fill out the following value as well:

 

• Value:  The URL of the HTTP server to contact when the location is selected.  You can indicate where to insert the URL Encoded terms of the query by inserting a “$w” into the URL.  Note that this is the same URL format as the one used for adding new deskbar shortcuts.

 

Now anytime you select your new Web Search location we’ll navigate to the locations URL using the terms entered into our query box.  For a Desktop Search location things are a little more interesting but follow the same principle as a Web Search location in that you need to tell us how we should filter your query.  But for Desktop Search locations we give you 3 different dimensions to filter the query by:

 

• ItemStore:  This is Unique ID (UID) we’ve assigned to the “store” you’d like us to filter results too.  Yes you’ve just discovered the part of all this voted “Most likely to change” in a future release.  Internally we use these things called UID’s to identify the various objects within our schema.  An “ItemStore” is one of the objects in our schema and we currently have 4 (see UID Values section for a list).  Just set this value to the UID of the store you want to search over. J
• TypeFilter:  This is an optional value you can set to filter results to a specific type within a store.  Again this is UID based and the UID’s are for the various “Type” objects within our schema (see UID Values section for a list).  If you omit this value or set it to 0x00000000 we’ll apply the filter to the query without altering the type selection.  That’s why you can select “Outlook” from the locations list and we filter to a new store without change the Type you have selected.
• Value:  Filters the query by appending a hidden Advanced Query Syntax (AQS) fragment to the query.  Also an optional value but probably the most interesting.  Using this value you can scope the query to anything you want using AQS.  For instance, the “Inbox” location scopes queries the “inbox” folder of the Outlook store by appending the AQS fragment “in:Inbox” to the users query.

 

Another thing worth talking about is the fact these locations get stored in HKEY_LOCAL_MACHINE.  That means the changes you make to this list of locations will be applied to every user on the machine.  But you can avoid that by copying the entire Locations hive to HKEY_CURRENT_USER and making your changes there.  That way each user can have their own list of locations if they’d like.

 

 

How’s this useful?

 

So hopefully all that made sense and you have a hundred ideas for new locations you want to create.  If so great!  Maybe we’ll even turn it into a supported feature in the future. J  But if not here are a couple of ideas worth considering:

 

• Personal Favorites:  I originally called this feature “favorites” and you can certainly setup your own list of favorite AQS fragments you end up applying all the time.
• Intranet Locations:  I think the Web Search locations are most interesting when thinking about deployments of WDS within organizations.  If you have a large organization with various SPS servers and such you might think about creating a standard list of locations that point to the searchable resources within your org.  You can then save that list off to a .reg file and install it on users machines as part of your deployment.
• 3^rd Party Add-in Locations:  If you’re a 3^rd party who’s developed a new protocol handler you can create a location for your protocol handler by scoping to the results view via AQS fragments.  To do this you'd want to append an AQS fragment of the form “store:myph” where "myph" is the name you've assigned to your protocol handler.  The tricky part of this is installing this location automatically on users’ machines.  You could blindly install it at Position 5 within the users location list but then you risk overwriting entries on machines containing modified location lists.  The safest thing to do would be to programmatically walk the users existing location list and install it as the last position on the list but that will require you writing custom code to do that.

 

Anyway… There are a couple of ideas and please let me know if you find this useful or have any comments… Enjoy!

 

-Steve

 

UID Values

 

ItemStore UIDs:

 

      uidStoreAny       = 0x30000001

      uidStoreFile      = 0x30000002

      uidStoreMAPI      = 0x30000003

      uidStoreOE        = 0x30000004

 

 

TypeFilter UIDs:

 

      uidTypeAny                  = 0x10000

      uidTypeAttachments          = 0x80000

      uidTypeContact              = 0xA0000

      uidTypeCommunications       = 0x60000

      uidTypeEmail                = 0x70000

      uidTypeCalendar             = 0x90000

      uidTypeIM                   = 0x160000

      uidTypeTask                 = 0xB0000

      uidTypeDocuments            = 0x20000

      uidTypeTextDoc              = 0x30000

      uidTypeNote                 = 0xC0000

      uidTypeSpreadsheet          = 0x40000

      uidTypePresentation         = 0x50000

      uidTypeMusic                = 0x100000

      uidTypePictureVideo         = 0xD0000

      uidTypePicture              = 0xE0000

      uidTypeVideo                = 0xF0000

      uidTypeFolder               = 0x110000

      uidTypeFavorite             = 0x120000

      uidTypeProgram              = 0x130000

      uidTypeMultimedia           = 0x140000