|
WPF and UWP are, one way or another, getting closer together with the formulation of XAML Standard.
In a year or so, this will generalize XAML to the point that UWP, WPF, Xamarin.Forms (and Unity3D assets like NoesisGUI) will all work with the same basic XAML.
Add that to the steady evolution of WebAssembly, and you'll end up with local HTML clients running C# and XAML somewhere around Q4/2018-Q1/2019.. if nothing goes horribly wrong.
My money is on UWP and WPF devs eventually migrating to HTML5/electron running C# with some iteration of XAML Standard. At that point, the boundaries between web and desktop apps will be gone, and everything else can be deprecated. 
|
|
|
|
|
That's an interesting view on the situation, but I think it may take longer simply because devs get so tied to technologies. Look at us still using WinForms. 
|
|
|
|
|
Working on it? It's been out for I don't know how many months.
|
|
|
|
|
Parts of it yes but there's a lot more surfacing they are working on.
This space for rent
|
|
|
|
|
raddevus wrote: it is really bad for MVC (the pattern, not the microsoft thing)
Really? Simply use the forms or controls as views and write yourself some nice baseclasses for the controllers (or presenters in my case). To completely get rid of the forms concept, you may also need some concept of a workspace. Easy as pie and I have ported code from ASP .Net web forms (a hack, I must admit) to WinForms, from there to WPF and from there to my own UI in XNA (now MonoGame).
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
Meanwhile, you'll be keeping the CPU busy and draining power, to render 2D surfaces, while your graphics card keeps idling and your users complain of a slow app, nevermind all the frame-skips. Native development is not like web-development, you don't just throw a few libraries and hack a UI.
|
|
|
|
|
André Pereira wrote: Meanwhile, you'll be keeping the CPU busy and draining power, to render 2D surfaces, while your graphics card keeps idling and your users complain of a slow app,
You don't say! If I only had known that. Fortunately I do use the graphics hardware to render the UI and that multithreded little monster uses a 3D engine to render into the background. The CPU barely breaks some sweat.
I have posted the link before: Take a look here.[^] And if you don't like my models or UI design, then that's ok. It simply means that I'm not much of an artist or designer. 
André Pereira wrote: Native development is not like web-development, you don't just throw a few libraries and hack a UI.
Thank god, otherwise our poor CPU would be tied up running some worthless interpreter (like JavaScript) and there will not be enough left for the 2D surfaces.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
Just as long as your users aren't on Windows XP or Window 7 on "classic theme", which disables 2D acceleration :p. Spread the good word. Don't let web-developers take over what used to be the top-tier experience in usability.
[RANT]God, just last week I had to hack some UI stuff on Android with a web-view. Spent 10 minutes developing the required stuff and 3 days debugging web-browser related stuff. And in the end, I still had to mask the page loading in the background, so it doesn't look awful (i.e. like a browser).[/RANT]
|
|
|
|
|
Mycroft Holmes wrote: what benefit is there to UWP
The "U" in UWP to me says it all: Universal. One codebase that runs on desktops, mobile (or at least used to ), tablets, Xbox, SurfaceHub, HoloLens, and IoT devices. That may not be attractive to all developers or for all use cases, but from my admittedly narrow understanding it opens up some pretty slick possibilities without the effort it takes to get other approaches working on multiple platforms.
Full disclosure: I'm not a developer but I am a Microsoft employee. Flame on. 
|
|
|
|
|
My non-canned response would be:
1 - It's the most recent and the most supported target for software development. (HiDPI screens, touch and pen, GPS and sensors with a simple native API).
2 - You don't immediately lock yourself out of target platforms, you get some choice. (Desktop is good enough, throw in tablet support for free and everything else is a nice extra.)
3 - Integrated store deployment and store updates (I still remember maintaining the self-updater on a legacy software, something that's obsolete now.).
99 - C# + .net + Xaml + MVVM = development bliss.
|
|
|
|
|
Just compare Spider Solitaire Win10 (UWP) and Win7.
Specifically, try re-sizing the windows both up and down.
Then ask yourself what is UWP good for.
|
|
|
|
|
WinForms, or better, the Common Controls, are very underappreciated; it is a mature product. A standard that is not just available on Windows anymore, as WinForms work just as happily under Linux.
I'm sure that WPF is better for graphics, as advertised.
I build tools for people that work. They don't care about flashy, they care about reliability and predictability. I'm not paid for animated borders, but functionality - and will probably still be maintaining WinForms code by the time that our great overloads predicted that AI will write code.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Interesting points and very interesting in light of the original conversation I had with the WPF-centric dev.
It has been my experience that winforms are good enough for corporate devs to get the job done and like you said they have a long history and been "production-tested" and just seem to work.
|
|
|
|
|
Eddy Vluggen wrote: I build tools for people that work. They don't care about flashy, they care about reliability and predictability. I'm not paid for animated borders, but functionality - and will probably still be maintaining WinForms code by the time that our great overloads predicted that AI will write code.
Absolutely agree. I’ve played with some of the newer GUI technologies myself and keep finding that the mature WinForms technology is the way to go. It might not be considered “flashy” but sure is reliable and gets the job DONE.
If you think hiring a professional is expensive, wait until you hire an amateur! - Red Adair
|
|
|
|
|
ClockMeister wrote: ...is reliable and gets the job DONE
And in the end, that's what keeps developers in business. I only write apps for my own use and occasionally a CP article. But everything is Winforms. As the old saying goes, "it just works."
Sometimes the true reward for completing a task is not the money, but instead the satisfaction of a job well done. But it's usually the money.
|
|
|
|
|
The thing about it is that WinForms applications aren't ugly, the data presentation can be very attractive and meaningful. In my case I've found that having a GUI so well worked out lets me focus on the problem-at-hand instead of spending all my time struggling to get the GUI working right. I have a web-based version of program I wrote for WinForms, it's fun to hack on from time-to-time but just getting the output right consumes a lot more time. I am certainly not against web-based presentation if needed, however if a WinForms application can do the job, the performance is far better and results very consistent. As for WPF (or any of the other cute technologies for desktop GUI) ... it's "hand waving" as far as I'm concerned.
If you think hiring a professional is expensive, wait until you hire an amateur! - Red Adair
|
|
|
|
|
The big problem with winforms apps we did at my old job was that the native controls all played badly with DPI scaling; a situation made much worse if you had any custom layout code/custom paint code that had an implicit assumption of no scaling in its math and got totally hosed up if you bumped the scaling levels.
Dunno if MS has made the situation better in Win8/10 than it was in 7 or otherwise in common libraries over the last 2 years or so. It never got past the list of things we were floating to our govt customer as potential upgrades/an internal pain point for anyone using scaling normally. My new job has WPFed for any desktop apps we do for DPI scaling among other reasons; needing to support older versions of windows means that UWP is a non-starter.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
WinForms works well with different scalings; the options for docking and anchoring make that rather easy. I'd daresay it scales as it should, instead of the modern zoom that most people nowadays apply.
It is a well documented library, that many developers are proficient in (making maintenance cheaper), and one that is recognized instantly by many users 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Scale by zooming is the only usable method on 200-300 DPI laptop displays; and if you don't want your half blind but too proud managers to set their 1080p/1440p monitors to 1280x1024 and then complain that all your graphics and text look all stretched out of shape and weird you need to support DPI scaling on normal desktop displays. These options look much sharper if you're able to draw at high DPI directly instead of at 100% and having it stretched by the OS.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: having it stretched by the OS.
It is not stretched by the OS; the developer has to specify which areas can grow and shrink. Depending on whom you are catering to, you'll be switching both DPI and resolution to verify the results.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hi, Raddevus,
As someone who has spent far too much time wrestling with the quirks of the MS supplied WinForm Controls ... many of which are .NET wrappers around old COM.ActiveX Controls ... I have a less "rosy" view of them: imho, they are a herd of cats
From the "cup is half-full" perspective, you could say that MS enabled a market for 3rd. party control developers to create much more powerful and internally consistent controls, with consistent API's. I remember, so well, my elation when I discovered Andrej Stojkov's Lidor TreeView Control: felt like I had gotten out of jail
I was excited, initially, by WPF's promise of an all-vector rendering engine, bubbling event-model, superior binding facility, etc. And, of course, symbiosis with a web-stack, SilverLight.
There was some great work done here, on CP, by pioneers like Clifton, Adrian Alexander, O'Hanlon, Josh Smith, Sacha Barber, and others.
The reality of programming in Visual Studio with WPF, however, just was not right ... for me.
Then, came the debacle of Metro, the deprecation of SilverLight, the failure of Metro, MS VP Sinofsky's (Metro honcho) departure, the WinRT hoop-la, etc. A lot of devs felt burned; fence-sitters, like me, decided to stick with WinForms.
If only ... one can waste time fantasizing about ... WinForms had a retained-mode all-vector, 2d graphic engine, and WPF's event and binding facilities. A Designer.cs file-format that at least was more XML-like, or, even XAML like.
A few comments:
1. For WinForms TreeView and ListView that would be the 'HideSelection Property.
2. There is a more recent (2016) 2nd. ed. version of Nathan's book for Windows 10: [^], but it's listed as unavailable on Amazon, currently.
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
modified 13-Dec-17 21:42pm.
|
|
|
|
|
Really like your summary of the situation because that is my experience too.
I've been using those old controls since Win3.1 -- okay Win95 --- okay I guess they get updated once in a while but it seems like those are the same controls we've been working with since Win95 and you're right there is plenty about them that is bad / crufty / cracked.
But, since we've been working with them for 20 years we know how to get around those things.
I remember about the time Vista released I started messing around with WPF / XAML and wasn't that impressed seemed like a bunch of stuff to learn to draw my own controls when I could more easily drop a windows treeview on a WinForm app and be done. I'm no graphic artist so I let the TreeView be a TreeView.
Then the Silverlight debacle and all the rest just as you said.
Now Microsoft does the head-fake to UWP. I start learning XAML again and it is pretty cool.
But then you go to look for these things that must surely be easy even in XAML since people have been doing WPF / XAML, right? But you can't find the answers? It's all just crazy.
EDIT
Also, it is very interesting that the author changed that book's name to Building Windows 10 Apps from the previous name of Universal Windows Apps.
Makes me feel like Microsoft whispered in his ear something like,
"Uh, we're backing off the whole UWP/UWA thing, so..." ugh!
|
|
|
|
|
Just my $.02:
WinForms are really easy. And I mean, REALLY easy, I've enjoyed using them for years.
The click for me, when going to WPF, is: 4K monitors. If your resolution is high-res (such as, for 4K), WinForms are taking a really big fall. About close to 2 years ago, I got a laptop with 4K resolution. At this point, things starting to go downfall. What you see in the VS designer, is not what you will see visually. Some of the controls you create will look incredibly messy. The AutoScaleMode : if you go with Font, it will look horrible. If you go with Dpi, sometimes it's decent, sometimes not - what I've found is that most of the time, as long as I keep the form/control under 1900x1080, it's ok; and as a side-note, never go with None.
Now, add to that the Anchor property - which I used heavily to properly align controls. It seldom works on high resolution monitors.
What you end up is pretty much "try to see if it works". And "if" it works, you need to then test at other resolutions. So, long story short, as monitors get higher and higher res, WinForms is losing ground.
Now, onto WPF - really steep learning curve, but the results can be amazing. A lot of things will once again be "trial and error" at first, but once you get the hang of it, and if you have some pretty fancy UI in mind, WPF can definitely help you there. That, and Resharper 
Best,
John
-- Phot-Awe - Find the Photos you Love - FAST!
|
|
|
|
|
Great post and info.
John Torjo wrote: Now, add to that the Anchor property - which I used heavily to properly align controls. It seldom works on high resolution monitors.
I suffered this problem with my winforms when the new higher resolution and wide screens came out.
|
|
|
|
|
Thanks
One other issue I just remembered - sometimes, when lots (I mean, LOTS) of controls on a dialog/usercontrol, the VS2013 designer crashes a lot of times - so, editing the dialog/usercontrol is a huuge pain. I would have expected this to be solved later on (VS2017), but turns out this is not the case.
Best,
John
-- Phot-Awe - Find the Photos you Love - FAST!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
