Port the .NET 5 winforms TaskDialog API to WPF

[mveril]

Hi
I use Task Dialog in several WPF projects. I first used the WindowsAPICodePack library then Ookii.Dialogs. But I would have liked an official implementation. This implementation is now available in Windows Forms dotnet/winforms@5fbdbde thank to @kpreisser that create the following issue dotnet/winforms#146. Would it be possible to port this implementation to WPF ?
Thank you

[batzen]

I am wondering what should be ported exactly? Would just using the dialog from windows forms have any disadvantages?

[mveril]

I am wondering what should be ported exactly? Would just using the dialog from windows forms have any disadvantages?

The idea is the same as #438. I find it unfortunate to have to use the Windows Forms UI framework only for one or two dialog boxes.

[glyad]

I am wondering what should be ported exactly? Would just using the dialog from windows forms have any disadvantages?

1. I can't find any reason for to make my app depending on Win32 or WinForms libraries. I work with MS technologies about 30 years and know that MS can shutdown a framework within a week or after 20 years without any relation to how this framework is usable in the industry.

2. The idea (philosophy) of WPF is to have UI Control as "lookless". It means there is no look-n-feel code is in control's class. All of the things related to visual appearance of the control are separated as XAML resources and may be redefined. For certain cases, where is no way to ensure control's functionality, it's possible to obtain references to visuals (PART_[s]) and that's all. The Win32 dialog isn't customisable.

3. The strange of XAML based frameworks, which allows us to build fully customised UI, becomes broken with old-fashioned common dialogs.

4. The answers of MS managers show that MS want to make WPF unportable forever. Sad!

[weltkante]

Here's how the same proposal is "done right" for WinUI: add a TaskDialog control in the spirit of WPF instead of exposing the WinForms version in a WPF/WinUI API. WinForms is the wrapper framework for Win32, WPF/WinUI should be doing skinnable versions and not just re-expose what WinForms already does.

[glyad]

Here's how the same proposal is "done right" for WinUI: add a TaskDialog control in the spirit of WPF instead of exposing the WinForms version in a WPF/WinUI API. WinForms is the wrapper framework for Win32, WPF/WinUI should be doing skinnable versions and not just re-expose what WinForms already does.

Thank you a lot! You're right, it must be defined in the way pointed. Who is the HERO? :)

[miloush]

I disagree. A system dialog should look and behave consistent with the system.

[weltkante]

I agree that it should provide the system look and feel by default but WPF already reimplements the whole common controls system look and feel while still allowing user replacements, so why not allow user replacements of dialogs as well?

Though considering the activity on the WPF repo this point is probably moot anyways, all activity moved to WinUI.

[miloush]

@RussKie the dependencies might not be very obvious, maybe it would be helpful to point them out?

[miloush]

I am in need of using TaskDialog too and I am willing to contribute it to WPF, that is, the Win32 API wrapper.

@RussKie AFAIK WPF depends on Winforms only through WindowsFormsIntegration (for obvious reasons) and through PresentationUI (for document signing and other DRP dialogs). Most WPF applications therefore do not have Winforms loaded and I sympathize with the reluctance to load a 13 MB assembly just to pinvoke an OS dialog.

I would however be interested in what features of TaskDialog people use @mveril and others? Most notably, do you need to modify the dialog content while its shown? Do you add extra controls? Because my needs would be already satisfied by having an API similar to MessageBox, i.e. a static method like

int? TaskDialog.Show(Window owner, string instruction, string content, string caption, params string[] commandLinks)

showing e.g.

and returning simply the index of the commandLink clicked.

[RussKie]

WPF isn't dependent on Windows Forms at runtime, I've corrected my statement above.

That said, both WPF and Windows Forms are part of the Windows Desktop workload, and they are bundled together. You can see that under C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App\<version>\. So, there's no real overhead for a WPF app to reference Windows Forms assembles (or the reverse). Besides self-contained scenarios, perhaps.

[DanFTRX]

Self contained is a pretty big scenario though.

[RussKie]

Windows Forms is still there:

md selfcontained
cd selfcontained
dotnet new wpf
dotnet build
dotnet publish --self-contained

selfcontained>cd bin\Debug\net7.0-windows\win-x64\publish

selfcontained\bin\Debug\net7.0-windows\win-x64\publish>dir /b/s system.windows.forms.dll
selfcontained\bin\Debug\net7.0-windows\win-x64\publish\System.Windows.Forms.dll

[Molinarius]

I would however be interested in what features of TaskDialog people use

I use title, main instruction, command links with a note, progress bar, timer event, hyper links, main icon, window icon, footer, footer icon, verification.