1

On Windows 7, I developed a shell namespace extension (NSE) that presents a hierarchy of data that is very similar to a file system. Its junction point is the Desktop. I am able to click the [+] of each node in the tree control of Windows Explorer to expand that node. When I click on a folder in the tree view, I see a list of "folders" and "files", as expected, in the view presented by DefView. If I double-click on a "file", DefView dutifully invokes my corresponding IShellFolder::CreateViewObject to ask for IContextMenu, then eventually invokes IContextMenu::InvokeCommand, at which point I execute ShellExecuteEx with lpClass set to the extension of the "file". Explorer then dutifully launches the appropriate EXE application according to the "file" extension with my weird "file" path supplied as a command-line argument. However, if I double-click on one of my "folders" in the DefView, Explorer refuses to browse into the folder. An analysis of the call stack reveals that Explorer is trying to do some type of zone-checking on my weird "file" paths. I tried fiddling with Control Panel->Internet Options->Security zones, by adding my weird "file" paths to various zones, but that did not work. I can see from the call stack that there are two zone checks: a primary and a secondary. I guess I could brute-force my way around this, but I would like to know the sanctioned way to get past these zone-checks, or, rather, to get Explorer to browse into my "folders". Strangely, the IFileDialog does not have this problem, and browses into my "folders" without hesitation. I also tried adding the following code to my IShellFolderView::MessageSFVCB:

switch (uMsg)
{
    case SFVM_GETZONE:
    {
        DWORD zone = URLZONE_TRUSTED;
        * ((DWORD *)lParam) = zone;
    }
    return S_OK;
...

That did not help.

I also have a strong feeling my drag-and-drop will be blocked for the same underlying reason.

Any ideas?

Here is (partial) call stack:

MyDLL.dll!MyShellFolder::GetAttributesOf(unsigned int uCount, const _ITEMIDLIST * * aPidls, unsigned long * pdwAttributes) Line 385 C++
shell32.dll!CShellItem::GetAttributes(unsigned long,unsigned long *)    Unknown
shell32.dll!CDefView::_SelectionHasFolderJunction(void) Unknown
shell32.dll!CDefView::_ZoneCheckFrame(unsigned long,int)    Unknown
shell32.dll!CDefView::_InvokeContextMenuVerbOnSelectionWorker(char const *,unsigned int)    Unknown
shell32.dll!CDefView::_InvokeContextMenuVerbOnSelection(char const *,unsigned int)  Unknown
shell32.dll!CDefView::OnActivateSelection(unsigned long)    Unknown
ExplorerFrame.dll!UIItemsView::WndProc(struct HWND__ *,unsigned int,unsigned __int64,__int64)   Unknown
  • Explorer does call on lots of things that are not necessary to implement, I doubt your problem is related to security, it's more likely a problem with your code. Double-clicking on a Shell item is the same as invoking the default context menu item (the bold one) on that item. By default, folders have the "Open" context menu item (verb = open) as the default one. You don't want to call ShellExecute blindly on every invoke. For this one (and actually for every item), you should pass the action to DefView. How do you create context menu (SHCreateDefaultContextMenu?). Post a reproducing project; – Simon Mourier Sep 23 '21 at 05:58
  • I create my context menu manually. As mentioned, IContextMenu::InvokeCommand works for my "files" but never gets called for my "folders". I edited my post to show the call stack on double-click of one of my "folders". – HackTheStack Sep 23 '21 at 07:13
  • 1
    You should try with the default menu check everything works ok. It's not because you see a stack that calls on something you don't know that it's the cause of your problem, the Shell uses hundreds of interfaces. Also make sure your folders have the SFGAO_BROWSABLE attribute. Difficult to say more w/o reproducing code. – Simon Mourier Sep 23 '21 at 07:28
  • Almost unrelated but why are you forcing lpClass? Anything registered normally works with it set to NULL. Other apps are not going to set it... – Anders Sep 25 '21 at 23:43
  • Does https://www.codeproject.com/articles/17809/host-windows-explorer-in-your-applications-using-t act like Explorer or IFileDialog? – Anders Sep 25 '21 at 23:50

0 Answers0