[VB6] Common Dialog Replacement - IFileDialog Vista+ (No TLBs)

No longer supporting this version. A newer (better) version that is much easier to use has been posted at this location.

Updated/Revamped a bit: 17 Jan 2015

Attached is a working example of using the IFileDialog interface introduced in Vista. It is the replacement for the common dialog used for opening/saving files and browsing for folders. This code is not compatible with XP and lower. You should ensure your project has needed logic to verify system is Vista or better. This version does not currently support enhancements provided by Win7 and above. I do plan on adding them in the near future. This class-only solution is based off of my project: Creating COM Interfaces without TLBs

The classes are plug & play. No TLB references are required. The main class is the IFileDialog class and can be used-as is. The optional IFileDialogEvents class is provided so that you can receive callbacks while the IFileDialog is displayed. Before Vista, this would have required subclassing the dialog, but Vista provided a way to do this through simple callback events. This optional events class is not required to display the dialog. But that class is required if you want callbacks, wish to filter what is displayed in the dialog, or want to add your own controls to the dialog. That class must be implemented if used. This means adding a line of code in your declarations section: Implements IFileDialogEvents. Lets talk about the three types of events. You can opt to have any of them or none of them.

Each event sent from the class includes a reference to the Dialog, a user-defined key for the instance of the Dialog, and appropriate event-driven parameters. Some events expect an answer back from you. Though all events will be added when you Implement the class, you only have to code for the ones you asked for & want to respond to.

1. Standard Callback Events. The IFileDialog can forward events to whatever is displaying the dialog. The most common events are: DialogOnInit, OnFolderChanging, OnSelectionChange, OnFieOk. The OnFileOk event occurs just before the user is about to close the dialog and offers you a chance to prevent closing the dialog and/or cache any custom control properties set by the user while the dialog was displayed. The OnFolderChanging event offers you a way to prevent the user from navigating to what they clicked on. There are a few other events that are forwarded and can be reviewed on MSDN. Note: DialogOnInit is a custom event the class sends. It is intended for you to finalize any custom controls you may have added, i.e., setting an option button, selecting a combobox item, etc, before the dialog is displayed. Any actions you take will not be forwarded back through events until DialogOnInit returns. Should you need to actually subclass the dialog, you can do it at this time since the hWnd of the dialog is known.

2. Filter Events. We all know we can assign filters to a file dialog like *.exe, *.txt, *.dll, etc. The dialog offers a more advanced filter where you can individually choose whether what is returned during navigation is actually displayed. When the filter is active, Windows sends you, one by one, every item that would be displayed. You can opt to say yes or no. Note: This was deprecated in Win7 & may not be added back.

3. Custom Control Events. You have the option to add controls to the dialog. These include combo/check/text boxes, option/command buttons, labels, & menu-like controls. There is little point in adding controls if you have no way of knowing if the user is clicking on them. So the dialog can send you some events. However, these events are lacking in my opinion. They do offer basic stuff, like something was clicked, something was selected, but little else. Any added textbox controls, for example, have no events passed. There are no got/lost focus events for the controls. Locating these controls for manual subclassing will be a challenge.

Here's the gotcha. As mentioned, this is not compatible with anything lower than Vista. But you also must get outside of your comfort zone a bit too. Where the older common dialog returned file & folder names, this new version returns objects as IShellItems and IShellItemArrays (when multi-selecting items). That's really not a bad thing. Not only can you have these items give you the file/folder name and 'display' name, you can ask it to give you that name as plain text or as a URL or a few other formats. You can have it give you file attributes of the object. Since no TLBs are used, the IFileDialog class has methods that will allow you to query the returned object for those things.

What I don't like about this new implementation of the dialog? The folder browsing is too limited in my opinion. The older version allowed several flags to restrict what was displayed. This new version has very little options for folders. Win7 added the ability to restrict browsing to the local domain, but other than that, not much. The lack of options from previous version lends to possibility of needing custom filters (#2 above). Additionally, the previous version allowed files to be displayed with folders when browsing for folders. The new version doesn't have that ability. Matter of learning to adjust I guess, but I feel code for the older version of folder browsing may still be worth keeping around.

These classes don't have all the dummy-proofing I tend to add in. It's a work-in-progress. But it is important you become familiar with it before attempting to use it for any serious projects. And come back occasionally to look for updates.

What advantage does this have over TLBs? Only one I can think of: can create a class that can be added to any project without needing to carry over TLBs into the target application.

The sample project does not touch all the properties the IFileDialog class offers. Explore a bit.

DISREGARD... I'll leave this up for information / future users.
Problem was original definition of IModalWindow included
[call_as(Show)] HRESULT RemoteShow([in, unique] HWND hwndOwner);
and that needed to be deleted entirely instead of left in as a separate function.


I've been working on this through another way, not sure if you could offer any input... whenever I call SetOptions, VB crashes. If I call other functions, like SetTitle, SetOkButtonCaption... it calls the next vtable function instead of the correct one- SetTitle sets the OK button caption, and SetOkButtonCaption sets the file name caption.

Code:

---

[
        odl,
    uuid(42f85136-db7e-439c-85f1-e4075d135fc8)
]
interface IFileDialog : IModalWindow
{


    HRESULT SetFileTypes(
        [in] LONG cFileTypes,
                [in] LONG rgFilterSpec);
        //[in] COMDLG_FILTERSPEC *rgFilterSpec);

    HRESULT SetFileTypeIndex([in] UINT iFileType);

    HRESULT GetFileTypeIndex([out] UINT *piFileType);

    HRESULT Advise(
        [in] IFileDialogEvents *pfde,
        [in,out] LONG *pdwCookie);

    HRESULT Unadvise([in] LONG dwCookie);

    HRESULT SetOptions([in] LONG fos);

    HRESULT GetOptions([in,out] LONG *pfos);

    HRESULT SetDefaultFolder([in] IShellItem *psi);

    HRESULT SetFolder([in] IShellItem *psi);

    HRESULT GetFolder([out] IShellItem **ppsi);

    HRESULT GetCurrentSelection([out] IShellItem **ppsi);

    HRESULT SetFileName([in] LPCWSTR pszName);

    HRESULT GetFileName([out] LPWSTR *pszName);

    HRESULT SetTitle([in] LPCWSTR pszTitle);

    HRESULT SetOkButtonLabel([in] LPCWSTR pszText);

    HRESULT SetFileNameLabel([in] LPCWSTR pszLabel);

    HRESULT GetResult([out] IShellItem **ppsi);

    HRESULT AddPlace(
        [in] IShellItem *psi,
        [in] FDAP fdap);

    HRESULT SetDefaultExtension([in, string] LPCWSTR pszDefaultExtension);

    HRESULT Close([in] LONG hr);

    HRESULT SetClientGuid([in] UUID guid);

    HRESULT ClearClientData();

    HRESULT SetFilter([in] IShellItemFilter *pFilter);
}

---

I had tried both ways with the first entry, no luck. All entries are visible with their correct arguments in VB. GetOptions crashes VB too.

fafalone. I'm confused. Are you talking about your implementation of your TLB or my classes? If my classes, you wouldn't be calling the VTable functions directly, rather you'd use the properties I provided.

Quote:

---

Originally Posted by fafalone

whenever I call SetOptions, VB crashes. If I call other functions, like SetTitle, SetOkButtonCaption... it calls the next vtable function instead of the correct one- SetTitle sets the OK button caption, and SetOkButtonCaption sets the file name caption

---

Sounds like your interface definition is off by 4 bytes. Calling SetOptions and it is really calling GetOptions, then the passed parameter is treated as a variable pointer - crash if memory address doesn't exist else just a bad call. "SetOkButtonCaption sets the file name caption" you are lucky that that range of functions all have the same parameter type & count else that would crash too.

The only reason I can think that your VTable is off by 4 bytes is that your IFileDialog definition is not including the IModalWindow:Show method.

Yeah the vtable was thrown off because IFileDialog inherits from IModalWindow, and I had had RemoteShow as a discrete entry instead of omitting it.

But anyway, great project. Helped me understand a few things about the interface. In case you're interested I'll be posting an implementation using type libraries soon; it turned out to be a lot easier than anticipated, especially after a few concepts were cleared up by seeing what you had done.

Quote:

---

Originally Posted by fafalone

Yeah the vtable was thrown off because IFileDialog inherits from IModalWindow, and I had had RemoteShow as a discrete entry instead of omitting it.

---

Yep, hiding it would cause the shift :eek:

Trivial nitpicking.

I was pretty sure that the convention was to drop the "I" when you implement an interface as a creatable class, so shouldn't your implementation of IFileDialog be FileDialog?

Most Microsoft wrappers and TLBs do this, e.g. see "tom" (Text Object Model), MSXML, and many others.

Quote:

---

Originally Posted by dilettante

I was pretty sure that the convention was to drop the "I" when you implement an interface as a creatable class, so shouldn't your implementation of IFileDialog be FileDialog?

---

I waffled back & forth so often, just settled on it. Additionally, wanted it to potentially standout should some usercontrol or other class exist out there that doesn't include the "I". Convention be damned :)

Works for me! Just be sure if you change it to update comments and such. That bites me now and then.

The way I went with was IFileDialog, since it's just inherited from and not created directly, and then FileOpenDialog and FileSaveDialog, since they're what are being created with CLSID_FileOpenDialog.

Code:

---

//CLSID_FileOpenDialog
[ uuid(DC1C5A9C-E88A-4DDE-A5A1-60F82A20AEF7) ]
coclass FileOpenDialog {
        interface IFileOpenDialog;
}

---

Would it be possible to draw to the dialog?
I would like to draw a thumbnail (not natively supported by Windows) somewhere, when a file is selected.
I noticed the hwnd was available, but how would I resize the dialog to reserve a space for my thumbnail?

Quote:

---

Originally Posted by TomasEss

Would it be possible to draw to the dialog?
I would like to draw a thumbnail (not natively supported by Windows) somewhere, when a file is selected.
I noticed the hwnd was available, but how would I resize the dialog to reserve a space for my thumbnail?

---

In the DialogOnInit event, the hWnd is available but dialog is not shown yet. You can attempt to resize it at that point with APIS (MoveWindow or SetWindowPos). I think you will eventually have to sublcass the dialog to get professional results since I would assume when the dialog refreshes for any reason, whatever you drew would be erased. I have not played with this idea.

Have you considered setting the FOS_FORCEPREVIEWPANEON flag in the propFlags() property? Probably not exactly what you want though.

Thanks LaVolpe
I also suspect a resize would include a resize of the default content inside the dialog... so I would not get any empty space anyway.
The built in preview pane is fine with files supported by Windows. But I want to preview other file types not supported.
Another way around this is to write thumbnail providers for Windows to use for those file types. But that's another subject.
I would prefer to create the thumbnail myself on the file selection event and draw it to the dialog.
A third way would be to recreate the whole dialog as my own window in VB, but then it would not be "common" anymore and not follow the OS design.

Another option may be to use the preview pane and subclass the pane and that probably would be a pain

Edited. Maybe an old-fashioned option (button) added with a caption: Preview. When clicked, display a popup window with the thumbnail?

I met a problem from an API Printer dialog. The printer name is truncated into 30 Characters. Any way to create PrintDialogEx via CLASS or TLB to overcome this problem?

Haven't looked for a class that uses that API. As for the long printer names, I responded to your thread in the VB6 Forum. Per msdn, the DEVNAMES structure contains the full length name. In that reply, I added sample code to extract the name from the DEVNAMES structure and tested it with a long printer name -- works.

I must say, that IFileDialog Vista+ is an excellent work, actually! But I wonder how to use it to attach events to Dialog based IFileDialog which has created and shown by other code but in the same process.

In fact, I work in VBA and I need to get events of Word's Save Dialog (e.g. maintain the changing of file type etc.). There was quite easy with good old Common Dialogs - I hooked with SetWinEventHook to get hwnd of Common Dialog, subclass it, check the notification code of NMHDR structure of WM_NOTIFY message and finally get the appropriate CDN_* code (e.g. CDN_TYPECHANGE).

I've tried to implement IFileDialogEvents in similar way, i.e. firstly get the hwnd of File Save Dialog in SetWinEventHook callback function, but I'm not able to get the the pointer to the object of IFileDialog interface from hwnd which I could use to attach IFileDialogEvents to. I was thinking of using AccessibleObjectFromWindow function (as MSDN says that is able to get not only IAccessible, but also "IDispatch, IEnumVARIANT, IUnknown, or other supported interface pointer"), but I'm not sure if it could be a right way.

So I would like to ask you how to get such pointer to allow attaching the events. I hope, that it could be possible as either Word application code and VBA code runs as the same process.

Tough question and I don't know the answer, but I'll give you a little info that may help point you in another direction.

1. Using this project, I printed out the IFileDialog ObjPtr when the dialog was about the be shown, i.e., within the DialogShow method: Debug.Print Hex(ObjPtr(m_FDlg))

2. I then used Spy++ to look at properties of that dialog window

3. In the screenshot below, you can see the 3rd DWord contains a hex value. That hex value happened to be equal to: ObjPtr(myIFileDialog object instance) - 16. So, the pointer you may be looking for could be that value + 16? What is that pointer? I think it is IUnknown. Regardless, if it is indeed a object pointer, then you can use QueryInterface on that pointer to see if the object also supports/implements IFileDialog.
Attachment 128829

Caveats. Those extra bytes (extractable via GetWindowLong), may not contain same information from O/S to O/S. And if the dialog is a 64bit process, then more headaches potentially.

Good luck and if you do find a way of 'subclassing' the dialog within VBA, might want to consider sharing your success as a new thread to the codebank. Others may find it useful too

Edit: Misread question, will update this post soon, sorry

Thanks for this excellent class! I'm trying to implement it in a project of mine and have it working most of the way but one thing I can't figure out...

On the Save as dialog the user selects 1) the destination folder, 2) one of the filters from the Filters dropdown (let's say he selects EXE from a list of Executable file types). 3) In the FileName field he enters a file name with no extension. Then he clicks OK.

The file is saved in the correct folder, with the correct file name but the extension chosen from the dropdown of Filters is not added to the saved file name. What is the point of selecting a Save As Type from the dropdown if this extension is not going to be added to the saved file?

Or is this simply to filter the types of files shown in the window and not to be applied to the saved file?

[QUOTE=AAraya;5070993]
The file is saved in the correct folder, with the correct file name but the extension chosen from the dropdown of Filters is not added to the saved file name. What is the point of selecting a Save As Type from the dropdown if this extension is not going to be added to the saved file?
QUOTE]

Found the answer to my own question. The property I need to be setting is propDefaultExtension. The Property Let half of this has a typo - "propDefaultExtensions" has to be changed to "propDefaultExtension" and then this works great.

Thanks again for your work on this!

Thanks for this excellent project! My major application has been using the GetOpenFileName/GetSaveFileName APIs for many years, but suddenly this seems to be broken running under Server 2016 :-( Your classes are a lifesaver! One minor error in propStartupFolder_Set though:

Code:

---

   
 Case vbString
        If Left$(Path, 1) = "{" Then
            If Right$(Path, 1) = "}" And Len(Path) = 38 Then m_InitDir = Path
        Else
            m_AddPlacesm_InitDir = Path
        End If

---

Thanks again, cheers
Ian

You might want to try this other version... It is far less complex for the user.
http://www.vbforums.com/showthread.p...t-Another-One)