Wpf: 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.

[RussKie]

1. I can't find any reason for to make my app depending on Win32 or WinForms libraries.

WPF depends on Windows Forms.

[miloush]

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