[Question]: File and Folder Dialog Controls

[shaggygi]

This is more of a question at first, but can update the issue as a proposal if needed. I was wondering if there is currently or a plan to add File (Open/Save/Save As) and Folder dialog controls to WinUI?

[mdtauk]

Windows Core OS and Windows Lite is rumoured to have a new Shell built in XAML - so let's hope WinUI 3.0 will bring with it updated Common File Dialogs - as well as Pickers.

[shaggygi]

@mdtauk thanks for pointing that out. In addition, it would be great to have a modern message box and such.

[mdtauk]

@shaggygi UWP already has a couple of dialogs which take the place of the traditional MessageBox

ContentDialog

MessageDialog

Win32 MessageBox

[pag3]

Windows has APIs to get the common file open dialog, common file save dialog, and common folder picking dialog. They aren't part of the presentation platform per se, they are part of the core operating system shell.

If you're writing to the UWP/WinRT API family, use: FileOpenPicker, FileSavePicker, or FolderPicker as documented here: https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-using-file-and-folder-pickers.

If you're writing to the Desktop/Win32 API family, use the IFileOpenDialog, IFileSaveDialog, or (for folder picking) IFileDialog w/ the FOS_PICKFOLDERS flag APIs as documented here: https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/bb776913(v=vs.85)

Note: A benefit of picking the UWP/WinRT API is that they'll work for you even across non-Desktop devices like XBox, etc. If you're using .NET/C# then they also have the benefit of already being projected into .NET for you and don't require any other library to wrap them as the Desktop/Win32 APIs do.

Does that work for you? There's a ton of intricate code in the implementation behind these dialogs that is deeply coupled with the shell code itself, so it strikes me as unlikely we would try to lift those implementations out of the shell and into WinUI itself directly.

[pag3]

For message box type scenarios, I agree with @mdtauk you should consider using ContentDialog:
https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/dialogs-and-flyouts/dialogs

It provides the standard placement and formatting for the title, content, and action and close buttons for you by default.

[shaggygi]

@pag3 Thanks for the input. I overlooked the ContentDialog and will help for MessageBox related type UI. I think it would be nice to have a common control for file/folder interaction (open, save, etc.) especially since the roadmap is to work with WPF, UWP, etc. Not sure if possible, but one could hope 😄. Thanks again.

[mdtauk]

@pag3 When the new Shell comes out, written in XAML - I hope these common file dialogs will get a XAML update and a more modern look and feel.

Whether called from Win3.0 XAML apps, or older Win32 ABIs.

[pag3]

@shaggygi There are common controls for those dialogs and they are exposed via the APIs I mentioned. They part of the Windows operating system and should be callable for you whether you are using WinUI, WPF, WinForms, MFC, ComCtl32, or whatever for your presentation platform. They are independent of the presentation platform.

What are you hoping to get out of them being in WinUI explicitly vs the way they are exposed today?

[pag3]

@mdtauk In general, when we update system/shell ui components like the file picker dialogs, we try to make it so callers of the existing API get the new system/shell experience by default when the app is run on the os with that new system/shell experience. It’s not always possible to do so - for example if something about the API made assumptions about the experience that no longer held true after the redesign - but in general that’s what teams try to do with Windows System APIs.

For example, that Win32 API I mentioned has been around since Vista even though we’ve updated the user experience multiple times since then.

[mdtauk]

@mdtauk In general, when we update system/shell ui components like the file picker dialogs, we try to make it so callers of the existing API get the new system/shell experience by default when the app is run on the os with that new system/shell experience. It’s not always possible to do so - for example if something about the API made assumptions about the experience that no longer held true after the redesign - but in general that’s what teams try to do with Windows System APIs.

For example, that Win32 API I mentioned has been around since Vista even though we’ve updated the user experience multiple times since then.

I was under the assumption that those Win32, MFC, WPF apps would continue to function as is, unless they took on a dependency on WinUI 3.0 - or are part of a File > New Project.

And those platforms without Win32 legacy support (Windows Core OS, Windows Lite, Hololens, Xbox) wouldn't support those legacy pickers anyway.

So adding in documentation to identify what is deprecated, or including graceful fallback where needed could be part of the spec?

[shaggygi]

@pag3

What are you hoping to get out of them being in WinUI explicitly vs the way they are exposed today?

Thanks for the reply. While I'm trying to get up-to-speed with WinUI, I was wondering if it would be possible to have a common approach to interacting with files/folders instead of being required to code to specific platform (WPF, UWP, etc.). Meaning, if I have a class library that uses a WinUI control to save a file... I would like to be able to use within a WPF and UWP app. I'm assuming the UI might be a little different, based on the type of app.

For example, my team codes up a few common API services to use with our MVVM-structured apps. We currently only use WPF (limited by mixture of OSes and company policies), but would hopefully like to move forward using WinUI and such. Not a biggie right now... just trying to prepare a little for down the road 😄

Thanks again.

[contextfree]

@pag3
Thanks for the reply. While I'm trying to get up-to-speed with WinUI, I was wondering if it would be possible to have a common approach to interacting with files/folders instead of being required to code to specific platform (WPF, UWP, etc.). Meaning, if I have a class library that uses a WinUI control to save a file... I would like to be able to use within a WPF and UWP app. I'm assuming the UI might be a little different, based on the type of app.
For example, my team codes up a few common API services to use with our MVVM-structured apps. We currently only use WPF (limited by mixture of OSes and company policies), but would hopefully like to move forward using WinUI and such. Not a biggie right now... just trying to prepare a little for down the road 😄
Thanks again.

Not sure if this helps or not but note that there's a way to call the UWP FilePicker from a Win32 or WPF ap: https://devblogs.microsoft.com/oldnewthing/20190412-00/?p=102413

It does require an extra API call to specify the associated HWND, so I guess you wouldn't be able to just use the identical code and would still need to wrap and conditionalize it somehow.

[YuliKl]

This is a great discussion and I believe @pag3 answered the original question:

There's a ton of intricate code in the implementation behind these dialogs that is deeply coupled with the shell code itself, so it strikes me as unlikely we would try to lift those implementations out of the shell and into WinUI itself directly.

@shaggygi, I'm going to close this issue but please feel free to re-open if you need additional information.