ToggleSwitch, Fluent Design: Microsoft promises but seldom delivers

[ic2]

It's been a while since some Chit-Chat was added here so here I go.

As most of you know I am not a big fan of Microsoft. Here's another reason why. Microsoft is often bragging about their great plans and visions for the future. But most of it is not delivered or working well. A while ago I attended their on line conference Ignite and the sessions I saw did not inspire me at all let alone ignite anything. Often a lot of blah blah about nothing or something to come on some time. Yeah.

As you may all be aware, Microsoft put some effort in UWP programs which would work on every Windows device with minimal changes. After the (pretty nice) WinPhones failed there was not much advantage in developing UWP projects and the nice things exclusively created for UWP were planned to be available in all WPF programs. In this over 3 years old article, Senior Software Development Engineer Alexandre Chohfi explains how & why. In short:

At Build 2018, Kevin Gallo announced that Microsoft would be introducing a way for developers to use the new Windows 10 controls into their current WPF, Windows Forms and native Win32 apps, without fully migrating their apps to the Universal Windows Platform. That was branded as UWP XAML Islands, and it is huge!


See https://blogs.windows.com/windowsdevelo ... ve-part-1/


So we are over 3 years further and I decided that for a settings screen of a program I started some years ago I wanted to add some ToggleSwitches. You know, the modern version of a checkbox which can be set to on or off, like in Windows 10 Settings.

There's even a nice Gallery app (in the W10/11 Store) and it is described https://docs.microsoft.com/en-us/sample ... s-gallery/. Fluent Design, that is what we should use!

But then... it took me quite some to find out that this simply doesn't work in most cases.

First, I managed to find XAML Island and eventually found that this that targets .NET Core 3.1. So it targets an obsolete .Net version. Great!
https://docs.microsoft.com/en-us/window ... ml-islands

In the Gallery article, it is hidden somewhere that using this Fluent Design controls requires Windows UI Library and that points to the Windows App SDK, for which finally a WinUI 3 version as released (end last year) . But if I understand that correctly, it only works with .Net 5 (https://docs.microsoft.com/en-us/windows/apps/winui/).

This all is the usual Microsoft mess of promising to introduce new things widely soon and then multiple teams start working on their own solution only working on limited environments (Islands, WinUI) ; limitations you will only find after considerable time spent.

And now about my ToggleSwitch? Well, after some further searches I found a very easy to use set of controls called WPFSpark on https://www.codeproject.com/Articles/1060961/WPFSpark-v. For .Net targets>4.6.1 Framework, go to https://github.com/ratishphilip/wpfspark where the latest version supports the Framework until 4.7.2 + Core 3.1 and 5.0.

ToggleSwitch.jpg (5.46 KiB) Viewed 1667 times

Including the 2 DLL's in my project, I had a ToggleSwitch working in half an hour and I could read the value on saving the settings with the same line of code used for checkboxes (I avoid databinding wherever possible).

What I wonder is why a company that spends $ 68.700.000.000 on some game licenses, is unable to deliver a simple to use/include DLL with their latest Fluent Design controls which can be used in every .Net environment.....


Dick

[TerryB1]

Hi Dick

Yes - I must agree with what you say, or at least the sentiment behind what you say.

But I myself have had many good ideas over the years. Each on has been "the best idea since sliced bread". Each has remained that way until I was so pleased with it that I mentioned it proudly to someone else, who promptly came back with a better idea.


I think that this is what you are seeing here. MS asked its developer community on the best way forward. The response to that was, I think, a vote for Winforms and .Net evolution/enhancement.

MS has trown its weight behind Winforms and .Net is now version 4.8. (Interop with WPF is still possible but IMO Winforms direct gives finer control)

I suggest you look at that. It's come a long way recently. Again, a personal view is that other ways will die out over time, or not even take off.

Personally I find direct C# the easiest, but I see no reason for why the same thing could not achieved via XSharp (if not now, then some time in the future)

Best Regards

Terry

[ic2]

Hello Terry,

I think you fully right. Still, if a single developer can create a DLL offering 7 new UWP style usable in all WPF based .Net versions, why can't Microsoft make these available for Winforms & WPF? They can't even make it available to more than 1 .Net version.

I have indeed added a Winforms window for a treeview as I didn't manage to get the WPF version to do what I wanted. Earlier I added a directory/filename autocomplete Winforms textbox in a WPF window because autocomplete wasn't implemented in WPF.

I think I will continue to mix. Winforms is easier to realize and, as you state correctly, it seems (for now) more where Microsoft might be working on a bit more. But WPF is more flexible, like here with adding this DLL.

I found this in a recent forum post and that more or less sums it up:

WinForms and its Visual Studio designer are still broken, WPF is still riddled with bugs and was declared obsolete in ~2017 in favor of UWP, UWP is marked obsolete in favor of WinUI, and WinUI's OSS release was postponed just two days ago because it's not ready.

Microsoft is marketing .NET 6 as the replacement for .NET Framework but you still cannot properly do desktop UI with it. I honestly don't understand why they are pushing more and more features when they cannot complete the ones they started years ago. Not to mention that porting WinForms from .NET Framework to .NET 6 requires a rewrite for anything more complex than a Hello World.


Dick

[TerryB1]

Hi Dick

Yes I take your point about WPF being more flexible.

But I think, whilst there may be some truth behind the your italicised summing up extract, it is misleading.

The Visual Studio Designer is not broken. It may be a bit tricky to use, but that is because it is aimed at a user (developer) who is trying to convey, on a 2-Dimensional screen what is essentially a 3-dimensional image source. Just like the architectural plans for a building. As a minimum 2 are needed Plan and Elevation sometimes more. It is a projection of some sort and one view may obscure another.

In all cases this source image comes from the human brain:- To be interpreted by another human brain either directly or via some computerised process/application.

Winforms and Visual Studio 2022 looks to me to be the most promising way forward. The latter as I said earlier can or will be able to be tackled through XSharp.

As for WPF - easier perhaps, but effectively sits on top of Winforms and IMO offers a lower level of control, meaning developers can implement a "WPF-like wrapper" for themselves.

Terry

[ic2]

Hello Terry,

Two remarks about it:

1 I am always very reluctant upgrading any MS product, especially because usually features you are used to disappear silently. Take W11 where they replaced a (finally) quite usable start menu with an unusable start menu. No doubt going to VS2022 will have some unpleasant surprises which are worse than the alleged VS2022 advantages.

BTW If anyone using VS2022 has remarks about VS2022 (good or bad) I'd like to know these.

2 I was surprised to learn from the yearly Stackoverflow survey that developers leave VS en masse. VS Code (open source) us used by 71% against VS 33%, not much higher than Notepad++ (30%). See about halfway in https://insights.stackoverflow.com/surv ... llab-tools
Reasons seems to be that it is more configurable, faster and it runs on Linux.

Dick

[wriedmann]

Hi Dick,
only my 0.2 cents about Microsoft not being able to deliver controls that a one-man-show is able to deliver: IMHO they don't like to destroy the 3rd party market - and if you know that a control collection costs per year much more than a Visual Studio license, you may understand that.
(for a long time, I had refused to spend money for such a toolkit, but I needed both a very powerful grid and a RTF control, so I had to pay for one).
Wolfgang

[ic2]

Hello Wolfgang,

The above mentioned toolkit is free. The source code is on Github.

Microsoft engineers might learn from it how they can deliver their new controls to the whole range of frameworks instead of only one.

As I read in the past, and this is still valid" "Microsoft has some very good programmers. Only a few, but they exist". Extend this to those managing the programmers but I doubt there are even a few....

Dick

[wriedmann]

Hi Dick,
everyone needs good programmers, and a LOT of them are needed worldwide - lately also by the carmaker industries - look at Volkswagen and their 42Wolfsburg and their Fakultät73 academies - but unfortunately there are only to few around.
So you can be sure that even at Microsoft are a few geniuses and a lot of mediocre programmers..... and a single programmer can do a lot more than a group of mediocre programmers.
It may be enough to see what our "gang of four" here is able to accomplish with X#.
Wolfgang

[TerryB1]

Hi Dick/Wolfgang

Yes - I agree with points made and you're right to be cautious.

FWIW I have been developing an application using C# together with Winforms and recently easily and successfully brought the codebase into VS 2022 with Net 4.8.

I would recommend that anyone embarking on a Net 4.8/Winforms/VS 2022 looks at things from a total, fully integrated system point of view.

Each of those 3 entities brings something to the party. The whole is much greater than the sum of its parts.

You will find you have a development platform which allows you to code things up "through" entities with which you are already familiar, and by doing so you do in fact have direct programmable control over every pixel on your screen. In fact it goes deeper with colour in that you actually control every dot in every pixel. There is no finer level of granularity. Nor does it in fact amount to more than setting a colour on a control or bit of the screen.

WPF is there in spirit if not in person, the principles of Presentation Foundation are there. There are a few minor changes, for example a Canvas has become a Panel of some sort, which can be docked or scrolled in some way just as WPF. All very easy and intuitive thinking to get your head around.

So let's see what each brings to the party:

Firstly System.Windows.Forms (Namespace)
Brings with it the equivalent of WPF and Xaml. Allows controls etc to be encoded just as WPF was but uses Code throughout instead of Xaml.
Also brings with it a whole set of controls in Windows.Forms.UserControl namespace.

These controls have have names with which you will be familiar. There may be a few new ones to learn - fairly intuitive.
The main thing to be prepared for is that you have much more direct control over various bits of each control including on-screen positioning of that control and more events to which it can respond.

This means there is more to learn (if we want to capitalise on what is being offered) and to actually use it, more potentially to go wrong.

"Go Wrong potential" is minimised in VS2022 by its Form Designer and associated Property pages which essentially "computer check" your code.

Machine Learning has been incorporated into VS2022's intellisense system which when correct can reduce different key presses into simple single key presses (the TAB key). This makes coding quicker, but the downside is that you have to think quicker, and the ML bit can never be 100% accurate. A bit of a double edged sword in my opinion, but maybe I haven't used it on a single program for long enough.

Panels Etc
Simple enough in concept. They, like the Form as a whole, can be simply re-painted any time in a program by simply calling their invalidate function. The benefit of this is that time is saved by limiting redrawing to just a smaller necessary part of the screen and more code that you may have used before with WPF canvasses etc. is not now necessary.

Many new Namespaces have been introduced in the journey to Net4.8. Mathematical for example brings in floats, Rendering 2D or 3D - a bit more learning perhaps, but not as much as you may think. Bar Charts/ Histograms all the common diagramming stuff can be quite easily brought in to your programs presented on screen correctly annotated however you wish.

Finally, although I have not measured it, compilation time in VS2022 is noticeably less than VS2019.

Terry

[Karl-Heinz]

Hi Dick,
only my 0.2 cents about Microsoft not being able to deliver controls that a one-man-show is able to deliver: IMHO they don't like to destroy the 3rd party market ...
Wolfgang

Hi Wolfgang,

i remember very well: Due to the problems with the buildin VO-Databrowser Uwe Holz announced in the days of VO 2.0 in compuserve a new Databrowser written by the DevTeam. But because Joachim presented the first version of bBrowser this never happened - and as we know, that´s been a very good decision. Unfortunately this concept worked for CLIPPER, but not for VO: Create a compiler, a set of runtime functions and let the community do the rest

Many years ago i ve been in contact with Dietmar Bos - a former VO developer - about the infamous (OS/2 and Win) "Glockenspiel" lib. He never liked the lib and preferred to write an MFC interface instead. Maybe the VO story would have been a different story ...

regards
Karl-Heinz