In order to update the dialog while it is still running, you need to provide a pointer to an lpfnHook
callback in the OPENFILENAME
struct, and have the callback handle the CDN_TYPECHANGE
notification. It can send the dialog a CDM_GETFILEPATH
or CDM_GETSPEC
message to get the current filename, tweak it as needed, and then send a CDM_SETCONTROLTEXT
message to update the edit field (the ID of the filename edit field is 0x442
) with the new value.
Update: There is nothing wrong with your hook code. GetSaveFileName()
is deprecated starting in Windows Vista, replaced by (and becoming a wrapper around) the Common Item Dialog. The GSFN dialog UI is not altered by a hook in XP, so you must be using Vista+, in which case enabling the hook simply causes the wrapper to use different settings when invoking the CID internally. A lot of the new CID features are based on IShellItem
, not filename strings, so the wrapper removes anything that cannot be represented as a old-style filename, and makes the dialog look like the old-style GSFN dialog in XP and earlier. So what you are seeing is normal behavior for GetSaveFileName()
under Vista+! If you do not like it, then do not use GetSaveFileName()
anymore. Use the new IFileSaveDialog
interface instead. In fact, it natively changes the file extension for you if you configure multiple file types, designate one of them as the default extension, and then set an initial filename that matches the default extension. But if you wanted to, you can alternatively implement the IFileDialogEvents
interface in your code to receive OnTypeChange
notifications and then use the IFileDialog::SetFileName()
method to update the displayed filename as neded.