34 ms·

> I’d argue WPF is a lot easier even for simple apps. I could not disagree more. That might be true for you, if you are a person who has already spent a long t

> I’d argue WPF is a lot easier even for simple apps. I could not disagree more. That might be true for you, if you are a person who has already spent a long time learning WPF. It is not true in general; WPF is complex.

alkonaut 4y ago
Yes - This is in the context of "if you already know both frameworks reasonably well, which one lets you jump through the fewest hoops to get an app that has some minimum quality?". This is perhaps slightly different from "which one is easier to learn" or "which one can most quickly be used to create a an app for a controlled environment or with limited functionality". If you are trying to replace an excel sheet (i.e. the "VB6 scenario") then some people would find WinForms more intuitive. That's because it's more straightforward to iterate into something that appears to work, (which is an important quality of a framework that WPF is worse at). But there are some key weaknesses especially obvious in recent years, which makes you quickly hit a brick wall, not least around DPI. It used to be that you could mostly ignore DPI scaling, and in those circumstances the frameworks were much more equal in terms of usability. But now you'll quickly find yourself in the situation after developing that easy-to-bang-out WinForms app that a user reports that a control has scaled off screen so the whole program isn't usable at all. And now your situation is no longer "need to make an app quickly" but "need to learn two decades of layered workarounds in win32 scaling functionality". And that's one of those things that's even harder than learning WPF to the level where you can accomplish the same thing! You CAN use WinForms and simply accept some of the drawbacks, e.g. enable automatic scaling or disable scaling. While the App will look either blurry or tiny on a 4K screen, it's now a lot simpler to do. It might also be that your app is simple enough that automatic scaling works (But this is highly unlikely). I guess what I'm saying is that the days where you could spit out a native Windows App using something akin to a VB6 experience are more or less gone - because the landscape is now more difficult. Understanding deployment modes (store vs legacy, and so on), DPI scaling, UAC.. and so on and so forth, is a big undertaking. The VB6 era or even the 2005 WinForms experience isn't coming back. The landscape is more difficult.
- ripley12 4y ago
  Yeah, it's fair to say that the ceiling for what can be developed is higher in WPF. I'm unsure what problems with DPI scaling you're referring to. Last time I was working on a WinForms app (admittedly not an especially big one) I think I just needed to set the DPI awareness in the manifest and it worked OK. https://learn.microsoft.com/en-us/dotnet/desktop/winforms/high-dpi-support-in-windows-forms?view=netframeworkdesktop-4.8 https://learn.microsoft.com/en-us/dotnet/desktop/winforms/hi...
  - alkonaut 4y ago
    It works OK up to a point. There are traps everywhere. Some controls scale reasonably well, others don't. There is very little support for any vector drawing so you need to hand-roll resolution switching for assets (Admittedly, pixel based assets in WPF will require the same). Doing anything measure-based in code (rather than designer) such as placing items, requires remembering to manually multiply e.g. dpiScale * 16 to make a margin that will be 16px at 96DPI and 24px at 144DPI and so on. It eventually drives you insane.

alkonaut 4y ago

Yes - This is in the context of "if you already know both frameworks reasonably well, which one lets you jump through the fewest hoops to get an app that has some minimum quality?". This is perhaps slightly different from "which one is easier to learn" or "which one can most quickly be used to create a an app for a controlled environment or with limited functionality". If you are trying to replace an excel sheet (i.e. the "VB6 scenario") then some people would find WinForms more intuitive. That's because it's more straightforward to iterate into something that appears to work, (which is an important quality of a framework that WPF is worse at). But there are some key weaknesses especially obvious in recent years, which makes you quickly hit a brick wall, not least around DPI. It used to be that you could mostly ignore DPI scaling, and in those circumstances the frameworks were much more equal in terms of usability. But now you'll quickly find yourself in the situation after developing that easy-to-bang-out WinForms app that a user reports that a control has scaled off screen so the whole program isn't usable at all. And now your situation is no longer "need to make an app quickly" but "need to learn two decades of layered workarounds in win32 scaling functionality". And that's one of those things that's even harder than learning WPF to the level where you can accomplish the same thing! You CAN use WinForms and simply accept some of the drawbacks, e.g. enable automatic scaling or disable scaling. While the App will look either blurry or tiny on a 4K screen, it's now a lot simpler to do. It might also be that your app is simple enough that automatic scaling works (But this is highly unlikely). I guess what I'm saying is that the days where you could spit out a native Windows App using something akin to a VB6 experience are more or less gone - because the landscape is now more difficult. Understanding deployment modes (store vs legacy, and so on), DPI scaling, UAC.. and so on and so forth, is a big undertaking. The VB6 era or even the 2005 WinForms experience isn't coming back. The landscape is more difficult.

ripley12 4y ago
Yeah, it's fair to say that the ceiling for what can be developed is higher in WPF. I'm unsure what problems with DPI scaling you're referring to. Last time I was working on a WinForms app (admittedly not an especially big one) I think I just needed to set the DPI awareness in the manifest and it worked OK. https://learn.microsoft.com/en-us/dotnet/desktop/winforms/high-dpi-support-in-windows-forms?view=netframeworkdesktop-4.8 https://learn.microsoft.com/en-us/dotnet/desktop/winforms/hi...
- alkonaut 4y ago
  It works OK up to a point. There are traps everywhere. Some controls scale reasonably well, others don't. There is very little support for any vector drawing so you need to hand-roll resolution switching for assets (Admittedly, pixel based assets in WPF will require the same). Doing anything measure-based in code (rather than designer) such as placing items, requires remembering to manually multiply e.g. dpiScale * 16 to make a margin that will be 16px at 96DPI and 24px at 144DPI and so on. It eventually drives you insane.