Your best source of information and news about BIOS, vista and secrets on the internet

Vista ARTICLES TOP 50 Spyware Virus Vista SOFT Vista HELP

Coding

You are currently browsing the articles from MS Windows Vista Compatible Software matching the category Coding.

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”

Written by chrdavis on March 3rd, 2008 with no comments.
Read more articles on namespace and otherSoftware and extension and Search and Organize and shell and Coding and Programming and vista and search and API and Windows Vista.

Proper Shell Scripting on Windows Servers with Perl

  • Fact: Shell scripting is a must for any serious IT admin managing a server. From automating backups to checking logs and keeping server performance and load in check, scripting is a must.
  • Fact: Shell scripting on Windows sucks. Monad (Microsoft Power Shell) attempts to fix that, but so far the results are mixed.
  • Fact: Shell scripting on Linux and other *nix operating systems is powerful, well-documented, and quite straight-forward.

Most people take a look at these three facts, and instantly come to a conclusion.. the wrong conclusion: you can’t properly manage a Windows server because it’s inherently lacking in the shell scripting department.

Click to continue reading "Proper Shell Scripting on Windows Servers with Perl"

Written by Computer Guru on November 13th, 2007 with no comments.
Read more articles on Perl and Macintosh and Server Management and Shell Scripting with Perl and Batch and Bash and Operating Systems and Coding and Programming and Windows and Linux and Guides and Hacking and software.

Complete .NET Portability with Wine & Mono?

Mono is the open-source version of Microsoft’s .NET Framework. It implements most of the backend framework features, but unfortunately, falls flat on its pretty little face when attempting to display the user interface - which is what desktop apps are all about.

Wine on the other-hand, is a Linux port of (major parts of) Microsoft’s Win32 library - the core dependencies of the Windows development libraries, and more importantly, the win32 interface elements. With Wine, you can run many traditional C++ win32 executables on Linux, with certain limitations.

Mono’s biggest stumbling block is the GUI and .NET programs that use P/Invoke to call native non-managed win32 dlls - Mono is a pure .NET environment, and can’t handle them. But from the description above, that’s exactly what WINE excel at… So can’t we use WINE + Mono to make just about any .NET program run on Linux fresh out of the .NET compiler?

Unfortunately, the answer is no. Back when the Mono project was first starting out, the Mono development team considered using WINE to implement the System.Windows.Forms namespace of the .NET Framework (which is practically 100% native C++ unmanaged win32 code in .NET wrappers). But they made the right choice in deciding to not take the easy way and go that route, leaving the integrity of the Mono project intact and focusing on true cross-platform user interface libraries instead (the GTK# is now the UI Library of choice for cross-platform .NET applications).

Click to continue reading "Complete .NET Portability with Wine & Mono?"

Written by Computer Guru on September 19th, 2007 with no comments.
Read more articles on Coding and Alternatives and Mono and WINE and .NET Framework and c# and Windows and Programming and Linux and software.

Shell Namespace Extension: Adding Custom Command Module Items

Overview

In my earlier post, I showed how to create a Shell Namespace Extension using the default IShellView implementation (also known as DefView).  One thing you might have noticed from the sample is that the Commands Module is void of even the default items such as “Organize” and “Views”. 

Commands Module - FolderViewImpl

If you are developing your own Namespace and want to include the default buttons and/or add your own elements to the Commands Module as well, how do you accomplish this?  The answer:   you must implement the IExplorerCommand, IExplorerCommandProvider and IEnumExplorerCommand interfaces.

Below I describe what each of the interfaces is used for and what you need to do to properly implement them in your code.

IExplorerCommandProvider

After your Namespace is loaded, the Shell will ask your Namespace for an instance of an IExplorerCommandProvider.  This interface exposes two methods:  GetCommand and GetCommands.  The Shell calls the GetCommand method to retrieve a specific IExplorerCommand object that matches the supplied GUID (Each command is identified by a GUID).  The GetCommands method is called to retrieve an IEnumExplorerCommand instance.  This object enumerates all the IExplorerCommand instances for the namespace.

You Namespace is queried for its implementation of IExplorerCommandProvider via its IShellFolder's implementation of CreateViewObject.  The REFIID passed to CreateViewObject will be IID_IExplorerCommandProvider.  The Shell will then use this interface to retrieve your Commands Module items – which are implementations of the IExplorerCommand interface.

IExplorerCommand

The IExplorerCommand interface is used to provide the appearance and behavior of the item to Explorer’s Commands Module.  Most of the methods pass an IShellItemArray which identifies what items are currently selected in the view.  This information can be used by the implementation to customize the behavior for different selections or if no items are selected.  For example, if no items are selected, you may wish to set the state to ECS_DISABLED or ECS_HIDDEN to grey-out or remove the item completely from the Commands Module, respectively.

The methods exposed by this interface are described below.

Method

Description

EnumSubCommands

Returns an IEnumExplorerCommand instance used to enumerate sub commands of the current command.  The Shell will only call this method if the GetFlags method returns ECF_HASSUBCOMMANDS .  It is important to note here that while it is possible to do so, sub commands that have sub commands themselves are not encouraged. 

GetCanonicalName

Retrieves the globally unique identifier (GUID) associated with this command

GetFlags

Retrieves the flags associated with this command.  These flags specify the appearance and behavior of the command on the Command Module.

GetIcon

Retrieves an icon resource string.  This string is in the form of “myfile.dll,id”.  For example: “shell32.dll,-101”

GetState

Retrieves the state of the command item.  This is the first method of the interface that is called.  The state that is returned affects the appearance and behavior of the command item.  This method also passes a BOOL to let the command implementation know if the slow response rule is in effect.

GetTitle

Retrieves the string to display for the command item.

GetToolTip

Retrieves the string to use in the ToolTip associated with this command item.

Invoke

Called by the Shell when the user has activated a command on the Commands Module.

The above methods GetState and GetFlags return values that determine the appearance and behavior of the item in the Command Module.  In the table below are screenshots of the command resulting from the combinations of the flags/states values.

 

ECS_ENABLED

ECS_DISABLED

ECS_HIDDEN

NONE

ECF_HASSUBCOMMANDS

ECF_HASSPLITBUTTON

ECF_HIDELABEL

ECF_ISSEPARATOR

N/A

ECF_HASLUASHIELD

 

ECS_CHECKBOX

ECS_CHECKBOX|

ECS_CHECKED

NONE

ECF_HASSUBCOMMANDS

ECF_HASSPLITBUTTON

ECF_HIDELABEL

ECF_ISSEPARATOR

N/A

N/A

ECF_HASLUASHIELD

*ECS_CHECKBOX and ECS_CHECKED only apply to sub items

** ECF_ISSEPARATOR can only be added as a sub item

Slow Response Rule

The second parameter of the GetState method is a BOOL (fOkToBeSlow) that lets the implementation of IExplorerCommand know if the “slow response rule” is in effect.  If this value is FALSE, and your implementation performs slow operations (such as I/O, network calls or calls to out of thread COM objects) then your command should return E_PENDING.  This will cause the Commands Module to call the command’s GetState (and other methods) on a background thread with fOkToBeSlow set to TRUE.  This prevents slow operations in your implementation from running on the UI thread, thus preventing performance issues.

Command Item Ordering

It is important to note here that the developer of the Namespace Extension has no control over the ordering of command items.  For example, you cannot force your command items before the default View and Organize command items or have the View or Organize command items renamed/removed.  Items are simply appended to the end of the Commands Module in the order returned from the IEnumExplorerCommand instance.

IEnumExplorerCommand

The IEnumExplorerCommand is returned to the Shell by the GetCommands method of the IExplorerCommandProvider interface.  As the name suggests, it permits enumeration of the IExplorerCommand instances by the Shell.

FolderViewImpl Sample Code

The above interfaces have been implemented in the attached Shell Namespace Extension sample code derived from the FolderViewImpl SDK sample.  The structure of the command items (as well as sub items) is data-driven from an array of structures that define the command items (see the array of FVCOMMANDITEMs in fvcommands.cpp).   This approach was used to make it easy to experiment with the hierarchy of command items as well as their behavior/appearance.   The way you implement commands in your Namespace Extension may differ.

Commands Module - Modified FolderViewImpl

The above is a screenshot of the modified SDK sample.  Notice we now have the default command items (Organize and Views) as well as our custom items.  The Display command item performs the same function as right-clicking items in the view and selecting “Display” from the context menu.  The Settings button is used to demonstrate a command item with sub items.  All it does is display a message box with the name of the sub item when the user invokes the specified sub item.

It should also be noted that if you are using a custom view in your Namespace by implementing your own IShellView (instead of using DefView) you will need to include an implementation of IFolderView::GetFolder.  In your GetFolder implementation you will need to include the ability to QueryService for SID_SFolderView.

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
  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”

Written by chrdavis on September 5th, 2007 with 1 comment.
Read more articles on shell and namespace and Coding and API and Programming and vista and Windows Vista.