Question

I’ve been researching how to implement a Namespace Extension.

The NSE should show files and folders (they are physical files and folders, but located elsewhere on the disk).

Also, the NSE must behave as closely as possible to the normal Explorer view, e.g. it must have:

• Context menus that would normally appear in a normal Explorer view that are applicable to the file/folder(s) chosen
• Drag and drop (both of files/folders and other things like Document Scraps)
• ‘Right Drag and Drop’ (e.g. 7Zips ‘Extract here…’)
• Clipboard Copy/Cut/Paste
• Share With entries
• Any registered Shell Icon Overlay Handlers must work (e.g. Tortoise SVN/GIT)
• Column sizing/re-ordering
• View customisation, including ordering and grouping

So, basically anything the Explorer view can do so must we.

Looking at all the things that Explorer can do (that I used to take for granted), I felt a bit overwhelmed.

Because I’m both lazy and a realist (I realise it’d be near impossible to replicate all this functionality without issue), my plan is to reuse the functionality of the Explorer view in my NSE.

I’ve looked at various samples of NSEs. Most of these use virtual data, but as I said, I’m representing physical files and folder elsewhere on the disk. I’ve also read about the SHCreateShellFolderView method.

Armed with this information, I thought it’d be a relatively simple case of providing a PIDL of my root folder and then in my IShellFolder::CreateViewObject call SHCreateShellFolder method. Here is that method:

STDMETHODIMP CShellFolderImpl::CreateViewObject( 
    HWND hwndOwner, 
    REFIID riid, 
    void** ppvOut )
{
    HRESULT hr=E_NOINTERFACE;

    if ( NULL == ppvOut )
        return E_POINTER;

    *ppvOut = NULL;

    if (riid == IID_IShellView)
    {
        SFV_CREATE SfvCreate = 
        {
            sizeof(SFV_CREATE) 
        };


        if (SUCCEEDED(hr = QueryInterface(IID_PPV_ARGS(&SfvCreate.pshf))))
        {
            hr = ::SHCreateShellFolderView(
                &SfvCreate, 
                reinterpret_cast<IShellView **>(ppvOut));
        }

        SfvCreate.pshf->Release();
    }
    else if (riid == IID_ITransferSource)
    {

    }

    return hr;
}

No such luck with that. SHCreateShellFolderView was always returning E_NOTIMPL. Turns out that this is because it requires a pointer to something implementing IShellFolder2 (and IPersist2 for GetCurFolder where I can provide my PIDL). My folder just implemented IShellFolder and IPerist.

So after changing these to implement the newer interfaces, I got… nothing! The NSE would be loaded by Explorer, the constructor would be called, but immediately after, the destructor would be called. If I changed the interfaces back to how they were, it fired up (but still with the same problem).

I’ve since been looking for a sample that implements IShellFolder2, but again, the documentation is as bad as it is for the rest of these APIs.

How can I use SHCreateShellFolderView so that I don’t have to reimplement everything Explorer already does?

Answer 1

Even if you are able to use and embed a Windows Explorer window for your namespace extension, the problem is that you are no longer in control of what it does. For example, if the user double-clicks on a folder, the actual filesystem folder will be browsed, not your namespace extension node which represents the filesystem folder.

Your only option is to do your own implementation. Check out EZNamespaceExtensionsMFC which makes it very easy to develop namespace extensions. It has a “FileSystemBrowser” sample which you can use as a starting point.

DISCLAIMER: I work for LogicNP, the developers of EZNamespaceExtensionsMFC.