What is the difference between the new TFileOpenDialog and the old TOpenDialog?

Question

What is the difference between the new TFileOpenDialog and the old TOpenDialog?
In my computer (Win 7/DXE), when I run the code, the dialogs look the same.

Dextrocular

TFileOpenDialog implements Vista style open dialogs, but falls back to older style in previous versions of Windows. – Demonstration

@GolezTrol, TFileOpenDialog raises an Exception when run under XP. – Scurry

@Uwe Raabe. Can't test it, but I believe you're right. My mistake. – Demonstration

Answer 1

• TOpenDialog wraps the traditional GetOpenFileName. It works on all versions of Windows.
• TFileOpenDialog wraps the new COM based dialog that was introduced in Vista. It therefore only works on Vista or later. It has more functionality than the older dialogs, most notably the tight integration with search.

Vista common dialog

Compatibility common dialog

The GetOpenFileName API will in fact produce the new dialogs in most situations, if called correctly, so you can't actually tell the difference. That said, historically the VCL's wrapper for GetOpenFileName was implemented imprecisely and always resulted in the compatibility dialog being shown.

But what does the new COM dialog have to offer then?

The new dialog offers a much easier customisation interface at the loss of some generality. If you use the old dialog template based customisation with GetOpenFileName on Vista or later then the dialogs degrade to ugly compatibility versions that lack functionality.

The other big advantage of the new dialogs is the ability to select unlimited number of files. The old GetOpenFileName interface returned multi-select filenames in a fixed size buffer. This can be a real limitation and in my own code I have had to hack the VCL code to make this buffer larger for when my app runs on XP.

TOpenDialog will delegate the work to TFileOpenDialog if possible. The test it uses requires all of the following to be true:

• Running on Windows Vista or later.
• Dialogs.UseLatestCommonDialogs global boolean variable is true (default is true). This allows you to disable the use of the new COM dialog should you elect to do so.
• No dialog template is specified.
• OnIncludeItem, OnClose and OnShow events are all not assigned. Presumably these cannot be fired by TFileOpenDialog.

Summary

If you continue to use TOpenDialog then you will reap the benefit of unlimited number of file in multi-select mode. However, if you wish to customise the dialog, and have the new dialogs rather than the ugly compatibilty dialogs, then you need to do the following:

• On XP use TOpenDialog and the dialog template method.
• On Vista and later use TFileOpenDialog and implement customisation with IFileDialogCustomize.

Choriamb

Wait a minute, you and Uwe contradict each other. I remove the +1 but will restore it as soon as the issue is settled... I just checked, and Uwe is right. – Groningen

If I recall correct it was not imprecision on VCL's part, but the ever changing OPENFILENAME struct. VCL, being compatible with earlier OS versions, declared the smaller struct which resulted older dialogs to be shown. I may be wrong though.. – Blown

In Delphi XE2, there is another condition: StyleServices.Enabled must be true. Does anybody know why??? I use Win 7 with old styles, why are new dialogs disabled??? – Everara

@Everara That's a bug in the VCL. There are a number of similar bugs. That's one reason why I use my own wrappers to the system file dialogs. Same error was made with the task dialog wrapper. VCL coders not good enough. – Choriamb

Thanks for the confirmation. I thought it did not make any sense to disable vista dialogs just because of disabled styles. – Everara

@SertacAkyuz In fact it's down to the setting of OpenFilename.Flags := OFN_ENABLEHOOK in TOpenDialog.DoExecute. I guess that's needed in order to handle events. So that charge of imprecision is too harsh. – Choriamb

Answer 2

TOpenDialog executes TFileOpenDialog when the following conditions are met:

1. the program is running under Vista (and up)
2. UseLatestCommonDialogs is true (which is the default)
3. no OnIncludeItem, OnClose or OnShow events are set

So while still using TOpenDialog on your system you may likely end up automagically executing TFileOpenDialog in most cases, which explains why they are looking the same for you.

Remark: TFileOpenDialog does not fall back on older Windows systems (XP and under) - it just raises an exception. On the opposite, TOpenDialog does some sort of "fall forward".

Scurry

A couple of very minor gripes: 1) You missed any reference to the dialog template which should have appeared in your bullet points. 2) GetOpenFileName also usually results in the shiny new dialogs, so long as it is called in a particular way. I'm not actually sure whether or not modern versions of the VCL call GetOpenFileName in the appropriate fashion but this is somewhat moot now that TFileOpenDialog is used behind the scenes. – Choriamb

@David Heffernan, I actually looked at the Template property, but as it is protected and never set in the standard dialog components I decided to omit it here. Otherwise I would have to explain how to use it. – Scurry

Template is protected? I didn't realise that but I use my own wrappers rather than the VCL ones. The thing is though that dialog customisation is the main issue that leads you to use TFileOpenDialog. – Choriamb

So, the wise action will be to use the 'old' TOpenDialog in order to get compatibility with XP and 7. Thanks. +1 and accepted. – Dextrocular