Common Dialog NSE ParseDisplayName GetOpenFileName GetDisplayNameOf

Common Dialog NSE ParseDisplayName GetOpenFileName GetDisplayNameOf

Post by Le Chaud Lap » Sat, 08 Mar 2003 02:40:40



Hi All,

I have a namespace extension whose junction point is the desktop.

I would like to browse my extension using the File Open/Save As common
dialogs, but it's not working, and rather than fidgit until it mostly
works, I would like to understand exactly how paths are returned by
GetOpenFileName from the namespace to its caller.

As I understand things now, during browsing, my extension will have to
generate display names for the address bar of the common dialog, a
display name to be stored in registry MRU list, and a display named to
be ultimately returned to the caller of GetOpenFileName() and
parseable by CreateFile().

The sequence, as I understand it is:

1. User double-clicks on directory in view.  View calls
   pICommDlgBrowser->OnDefaultComand()
2. ICommDlgBrowser gets IDataObject from IShellView containing
selected
   PIDL's.
3. For PIDL selected (let's assume only one), ICommDlgBrowser calls
   GetDisplayName() to get text to be placed in dialog address bar.
   This looks like COMDLG32!GetViewItemText() in my trace.
   Neither SHGDN_FORPARSING nor SHGDN_INFOLDER is set, indicating that
   browser wants full path of selected item for display (why the whole
thing?).
4. Browser calls GetDisplayName() again, this time with
SHGND_FORPARSING set,
   but not SHGND_INFOLDER (why?).  I supply what would normally look
like
   fully-qualified UNC path, but instead of first part beign \\etc..,
   I use ::{GUID} instead, as this seemed to move things forward, and
makes
   it clear to the DesktopFolder how it should initiate parsing
process.
   COMDLG32!SwitchView()shows up in my stack trace.
5. Browser calls GetDisplayName() yet again, same flags, and my
extension
   gives it full pseudo-UNC path with first component replaced by
::{GUID}
   COMDLG32!SwitchCurrentDirectory() shows up in stack trace.
6. Browser calls ParseDispalyName on the ::{GUID} path above, but my
   extension, as of now, does not parse it.  I simply say the
attributes
   are 0, have not parsed any characters, and return.  Browser binds
to
   selected directory anyway and invokes new view of selected
directory,
   ready to repeate the process.
   COMDLG32!SwitchCurrentDirectory() still under invocation in stack
trace.

Now let's say that in the new directory, I select a file, and I have
done everthing outlined in Q216954.  At which point in the process
above, if any, is the path to ultimately supplied to GetOpenFileName()
yielded?  Or has the step not occured yet do to my empty
ParseDisplayName()?

The path that is being stored in commond dialog MRU list begins with
GUID, yet we know that GetOpenFileName() yields path paresable by
CreateFile()..so there has to be a distinction somewhere.  At
somepoint, I have to stop making
::{GUID} the first component and start using the actual \\Server...

What am I missing?

Thx,

-John-

 
 
 

Common Dialog NSE ParseDisplayName GetOpenFileName GetDisplayNameOf

Post by Le Chaud Lap » Sat, 08 Mar 2003 02:40:41


Hi All,

I have a namespace extension whose junction point is the desktop.

I would like to browse my extension using the File Open/Save As common
dialogs, but it's not working, and rather than fidgit until it mostly
works, I would like to understand exactly how paths are returned by
GetOpenFileName from the namespace to its caller.

As I understand things now, during browsing, my extension will have to
generate display names for the address bar of the common dialog, a
display name to be stored in registry MRU list, and a display named to
be ultimately returned to the caller of GetOpenFileName() and
parseable by CreateFile().

The sequence, as I understand it is:

1. User double-clicks on directory in view.  View calls
   pICommDlgBrowser->OnDefaultComand()
2. ICommDlgBrowser gets IDataObject from IShellView containing
selected
   PIDL's.
3. For PIDL selected (let's assume only one), ICommDlgBrowser calls
   GetDisplayName() to get text to be placed in dialog address bar.
   This looks like COMDLG32!GetViewItemText() in my trace.
   Neither SHGDN_FORPARSING nor SHGDN_INFOLDER is set, indicating that
   browser wants full path of selected item for display (why the whole
thing?).
4. Browser calls GetDisplayName() again, this time with
SHGND_FORPARSING set,
   but not SHGND_INFOLDER (why?).  I supply what would normally look
like
   fully-qualified UNC path, but instead of first part beign \\etc..,
   I use ::{GUID} instead, as this seemed to move things forward, and
makes
   it clear to the DesktopFolder how it should initiate parsing
process.
   COMDLG32!SwitchView()shows up in my stack trace.
5. Browser calls GetDisplayName() yet again, same flags, and my
extension
   gives it full pseudo-UNC path with first component replaced by
::{GUID}
   COMDLG32!SwitchCurrentDirectory() shows up in stack trace.
6. Browser calls ParseDispalyName on the ::{GUID} path above, but my
   extension, as of now, does not parse it.  I simply say the
attributes
   are 0, have not parsed any characters, and return.  Browser binds
to
   selected directory anyway and invokes new view of selected
directory,
   ready to repeate the process.
   COMDLG32!SwitchCurrentDirectory() still under invocation in stack
trace.

Now let's say that in the new directory, I select a file, and I have
done everthing outlined in Q216954.  At which point in the process
above, if any, is the path to ultimately supplied to GetOpenFileName()
yielded?  Or has the step not occured yet do to my empty
ParseDisplayName()?

The path that is being stored in commond dialog MRU list begins with
GUID, yet we know that GetOpenFileName() yields path paresable by
CreateFile()..so there has to be a distinction somewhere.  At
somepoint, I have to stop making
::{GUID} the first component and start using the actual \\Server...

What am I missing?

Thx,

-John-

 
 
 

1. NSE Common Dialog Browsing - Help Needed

Hi,

I am developing a document management system that is shown via a NSE.
I need to be able to save documents into my file system (with
multi-level subfoldering) through common dialogs such as the Word save
dialog. I have read and followed KB article 216954 but I am unable to
get the dialog to behave as expected and it always thinks that it is
in the root level of my extension. Does anyone know the correct way to
implement this functionality?

I am developing in VC++, VS.NET 2003, Win XP SP1. Any help would be
greatly appreciated.

Regards,
Dave Timmins

2. another newbie jumping into the fray

3. NSE/common dialog: resize problem

4. Organizer 97 - No luck with Ageneda Syncronizer-HELP

5. Properties dialog for NSE, Win98

6. Notebook computers

7. Animated copy dialog for NSE

8. HP DJ 400 Anyone ?

9. howto define actions to be performed when clicking on a nse in a open/save dialog

10. Forcing Dialog Filter to *.* from my NSE

11. Accessing NSE from a MS Office open/save dialog

12. Enumerating list of files under NSE fails second time after NSE device removed/inserted back

13. VBA in Excel--can you add a common dialog box?