Platform SDK Shell, Blank window in open/save common dialog when browsing NSE

Hi,

I have created a shell namespace extension using
SHCreateShellFolderView, which simply mirrors a local folder. I have my
own implementations of IShellView, IShellFolder, IContextMenu, etc.,
these forward calls to the system implementation when appropriate.

This extension works fine using windows explorer, it works in the
"browse for folder" dialog, and in the open/save dialog in Microsoft Office.

However, when I try to browse to my namespace extension in a normal
(i.e. common dialog) open/save dialog, no files or folders are shown.
The view is excactly as if the folder were empty. If I type a file name
and click OK, the file name is used correctly by Windows (e.g. if I
start notepad, choose Save As, browse to my namespace extension and
enter "myfile.txt", the file is saved to the correct path). I can also
right click in the view to get a context menu for the folder as usual.

I have verified that my IEnumIDList implementation is called and
enumerates all items in the folder.

I have also read KB216954 "How To Support Common Dialog Browsing in a
Shell Namespace Extension" and as far as I know, my namespace extension
conforms to the restrictions set forth in this article.

Any information on how to fix this problem would be most appreciated.

Regards,

Kenneth Pedersen

// Please remove ".spam" from my e-mail adddress to send mail to me.

You may want to try to intercept the SFVM_ADDINGOBJECT message
in a IShellFolderViewCB::MessageSFVCB callback function.

It is defined as #define SFVM_ADDINGOBJECT 29
It returns your LPITEMIDLIST pidl in LPARAM.

When you get this message, obtain a IShellBrowser interface and
use the IShellBrowser::IncludeObject method to include your LPITEMIDLIST
pidl.

You will then see your files displayed in the open/save dialog.

Correction after you get the IShellBrowser interface you must QueryInterface
for
a ICommDlgBrowser interface and call ICommDlgBrowser::IncludeObject

Additionally this call requires that you send a IShellView interface pointer
for the
active view.

ichael Phillips, Jr. wrote:

Thank you for the swift reply, but unfortunately this didn't work.

The SFVM_ADDINGOBJECT message is never sent. Apparently this is because
the common dialog does not add any items; the message -is- sent when
browsing the folder using explorer.

Also, my understanding of the docs for IncludeObject is that it gives
the common dialog a chance to tell the namespace extension if a given
item should be included or not (by returing S_OK or S_FALSE). Hence, the
appropriate place to call it is in the IEnumIDList::Next implementation
when enumerating subitems.

I do have a call to IncludeObject in my IEnumIDList implementation and
it seems to work -- at least filters in the open/save dialog in Office
work as expected, but then again Office may do its own filtering.

For reference, here is the code for my SFVM_ADDINGOBJECT handler:

case SFVM_ADDINGOBJECT:
{
ICommDlgBrowser *browser;

if(SUCCEEDED(m_pShellBrowser->QueryInterface(
IID_ICommDlgBrowser, (LPVOID *)&browser))) {

LPITEMIDLIST pidl = (LPITEMIDLIST) lParam;
browser->IncludeObject(this, pidl);
browser->Release();
}
}
return S_OK;

Regards,
Kenneth.

n the CDBView sample that comes with the KB article,
they use the IncludeObject method in the IShellFolder::EnumObjects method.

I used the same code as I described in my post and my NSE fills and filters
an Open/Save
dialog as expected.

It does not work with the Office dialogs. I believe Office uses custom
Open/Save
dialogs.

"Kenneth Pedersen" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

ichael Phillips, Jr. wrote:

In CDBView, IncludeObject is called from CShellView::FillList(), which
is called to add items to the list view control used in the sample.

while((S_OK == pEnumIDList->Next(1, &pidl, &dwFetched)) && dwFetched)
{
if(!m_pCommDlgBrowser || (S_OK ==
m_pCommDlgBrowser->IncludeObject((IShellView*)this, pidl)))
{
AddItem(pidl);
}
}

As can be seen from the code (from ShlView.cpp), IncludeObject is called
to decide if the given item should be added or not.

However, since I do not implement the shell view myself, but use the
system-provided shell view via SHCreateShellFolderView, I have no
control over which items are added to the list view. I have to rely on
the system-provided shell view to add the items that I return in my
IEnumIDList implementation. This seems to work well, -except- in the
open/save dialog.


Do you use SHCreateShellFolderView or implement your own shell view?
From where do you call ICommDlgBrowse::IncludeObject?

It does.

Regards,
Kenneth

Yes, MS Office has it's own set of open/save dialogs; these are the same
ones that make the "WantsForParsing" registry value necessary with a
namespace that supports real file system objects.


--
Chuck Chopp

ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com

RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
103 Autumn Hill Road 864 801 2774 fax
Greer, SC 29651

Do not send me unsolicited commercial email.

use SHCreateShellFolderView to created the shell view.

I call IncludeObject in my SFVM_ADDINGOBJECT message handler.
From debug tracing, I get this message sent to my callback
as part of the following sequence of calls:
IShellFolder::GetDisplayNameOf
IShellFolderGetAttributesOf
SFVM_ADDINGOBJECT

I call QueryActiveShellView first and pass that IShellView pointer to the
ICommDlgBrowser::IncludeObject method along with the pidl returned in
LPARAM.

"Kenneth Pedersen" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

My NSE works with the Office 2003 dialogs but not with the Office XP
dialogs.

I use the WantsForParsing registry entry.

The implementation of the Office Open/Save dialogs seems to be different
in Office XP than the common control dialogs provided by the system.

Is your NSE returning a valid file system path when GetDisplayNameOf() is
being called for the root folder of your NSE? That's a requirement with the
Office XP open/save dialogs. The reason is that the blasted open/save
dialogs in Office XP call GetDisplayNameOf() for every single item in the
fully quallified PIDL, verifying that every single element has a valid file
system path, instead of simply accepting the items in the namespace "as is"
until an item is finally selected for an open/save operation.

I don't have Office 2003 to test with, and haven't re-installed the older
Office 2000 for testing, yet.


--
Chuck Chopp

ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com

RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
103 Autumn Hill Road 864 801 2774 fax
Greer, SC 29651

Do not send me unsolicited commercial email.

My folder items are virtual. The file spec returned is a virtual path

consisting of "my namespace root filename.ext\folder\item.ext"

If the OfficeXP dialog does a file system check on the path, then it will
fail by design.

The common dialogs and Office 2003 dialogs do not check first if the file
spec
is valid. This allows my shell extension to return a path that can be
opened with
the shell api BindToObject method.

OK, then the quirky nature is limited to just the Office XP dialogs.
However, that quirky nature means that your NSE cannot be browsed by the
Office XP open/save dialogs unless you return valid file system path in
GetDisplayNameOf() [when it's called using the for-parsing flag] for every
path element described by the pidl that's passed in.

There's recent postings in this newsgroup regarding this issue from February
2005 & forward. I forget the exact KB article, but there's one of those,
too, that discusses the issue and some of the NSE related articles on
codeproject.com and codeguru.com also discuss the issue.


--
Chuck Chopp

ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com

RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
103 Autumn Hill Road 864 801 2774 fax
Greer, SC 29651

Do not send me unsolicited commercial email.