Common Dialogs (Open, Save As, etc.)
support is automatic when using ShellBoost. The ShellBoost native proxy
assembly will be loaded in-process implicitly by the hosting application
process as soon as it calls some Shell functions. In fact, this is not limited
to Common Dialogs, other Shell functions can end up loading your namespace
extension native proxy assembly in their process.
Here is the example of Notepad opening a
file in a “ShellBoost” namespace extension, just like it was a regular folder:
And here is the example of Microsoft Word®
2016 opening a file in the same extension (note this time the extension is in
details view mode and has an extra custom icon - for demonstration purposes):
However, any application that uses a Common
Dialog can customize the way it works. For example, many applications require
that the File Open dialog only displays Shell Item that are file system items.
These applications will not see fully virtual Shell Items. As a Shell Namespace
Extension developer, there is not much you can do about this, if you need to
support Common Dialogs for some specific applications, you will have to test if
it requires a file system shell item or not.
Technically, Common Dialogs are exposed
through Windows’ IFileDialog
interface. If you are developing an application and only need file system shell
items, you would use the IFileDialog::SetOptions
method with the FOS_FORCEFILESYSTEM
flag. If you want to support both physical and virtual shell item, then this
flag should not be specified.
Starting with ShellBoost 184.108.40.206, classes
deriving from Shell Folder instances can react to some Common Dialog events, as
demonstrated in the following code:
protected override void OnFileDialogEvent(object sender, FileDialogEventArgs e)
// OK/Open/etc. button was pressed
if (e.Type == FileDialogEventType.OnButtonOk)
if (!e.IsFileSave && e.CurrentSelectionIdList != null)
// we're in file open, get the item from its PIDL
var filePath = e.CurrentSelectionIdList.GetPath();
// TODO: do something with this...