|
Unfortunately, Embarcadero (formerly Borland) never managed to break through into the market.
But I don't know of any other tool that supports, among other things, inheritance of visual and data components as transparently and perfectly as they do.
But unfortunately they never managed to produce a reasonably stable version or a community or an Embarcadero ecosystem.
And of course this relatively small company Embarcadero has no chance of providing something equivalent to the .NET Framework.
|
|
|
|
|
Once you get the hang of it WPF is really nice and you can do a lot ito styling and customization.
|
|
|
|
|
This is exactly why I use WinForms. I don't want to style or customize. I'm a back end dev mostly. Dragging and dropping elements and using the mouse to resize is the most customization I want. From there, I can focus on writing code that actually completes the task I started with.
Hogan
|
|
|
|
|
Understandable. WPF can do drag and drop too, but if Winforms is easier for a simple ui then use what you're familiar with 
|
|
|
|
|
but then there's the DPI issue, which is the main reason I started to work more with WPF...then I fell in love with how WPF does databinding (yes, I know it can be done in Winforms too, but it was more of an afterthought and doesn't work quite as cleanly, IMHO)
|
|
|
|
|
And you found out WPF can also bind data async right?
That made a huge impact on my work before i had to switch to blazor and angular for the front end.
Rules for the FOSW ![ ^]
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");
|
|
|
|
|
I hadn't looked into it, but perhaps I should!
|
|
|
|
|
(And where is the "user" in all this? "I don't want to ...") With "flexibility" comes complexity. UWP and WPF are more "flexible" than Windows Forms. They actually have a "model" for the UI; it's called the "visual tree"; and it gives the whole thing meaning. Versus "drag and drop" (or drop and drag). The "designers" are "flat and 2d" and cannot intelligently construct "complex" (hierarchical) graphic interfaces. WPF and UWP requires a mental shift that "dabbling" doesn't scratch.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I'm a back end web developer currently, so my user is myself. I've built a few tools, but it isn't going to customers.
Hogan
|
|
|
|
|
Let's admit that your priority isn't creating "engaging user interfaces". Others seem only interested in delivering "fast". Nowhere have I seen a statement that one does what one does because it's what the "user wants".
I only create software that I would use personally; and that does not mean taking "short cuts". I said I "like" my tools; but that is only because they can deliver everything the user has asked for to date. Which includes "shiny".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
If I wanted to build "engaging user interfaces" I'd use AvaloniaUI or something, not WPF, which is already dated.
You sound like a snob. My apps are fine. Sometimes less is more.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
A "snob"? I find you arrogant. I can see why people leave. The "honey" mutual admiration society.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I only create software that I would use personally; and that does not mean taking "short cuts".
Implying I do.
Maybe pay more attention to what you write.
Then you won't seem like a hypocrite for taking offense after being insulting and being responded to in kind.
Just sayin'
Edit: If you're implying I'm the one that made Randor leave, you couldn't be more wrong. He and I are in contact on Reddit.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
modified 28-Feb-24 13:54pm.
|
|
|
|
|
Good question(s).
I'll hazard a guess and say perhaps some C++/MFC devs chose to not want to have to learn a new language and UI framework. In 2005, after a couple of years of using C# and .NET, I ported my MFC apps to WinForms and have never looked back.
/ravi
|
|
|
|
|
To get a developer to change is very difficult.
Mainly they can do it faster the old way and most of the time they don't have the time to learn the new way.
I worked for a mayor company, a long time ago that used C as their main language. When I came along and developed libraries, gave classes and tried to spend time teaching them C++ I had no takers.
Just an old hippie and don't know what to do;
Should I hang on to the old or grab on to the new? Bellamy Brothers
"Ten men in the country could buy the world and ten million can’t buy enough to eat." Will Rogers
PartsBin an Electronics Part Organizer - Release Version 1.3.1 JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
At "my" company we create a lot of small applications. Many of them have data grids to display e.g. a bill of material, tree-views, little bit of drag and drop, etc.
We wire this up way faster with Winforms than with WPF. The WinForms data binding isn't that bad. And there are almost never surprises that make you google for hours how to solve this weirdness. Maybe if we would use 3rd party controls like we do in WinForms (DevExpress), it would be easier. But plain WPF takes a ridiculous amount of time to make things work.
We also have two teams which work on big WPF projects for years now. They created awesome UIs. But the effort they put in for this is tremendous. So, if your customer is willing to pay for WPF, go for it. If you need it yesterday, go with Winforms 
|
|
|
|
|
...and our core development team is using C++ and MFC. It's an ECAD system which is in devolopment for over 20 years. Was once ported from HP workstations to windows (Electrical Design Software | E3.series | Zuken EN[^])
There is no way to rebuild all of this in WPF, MAUI or what ever.
|
|
|
|
|
WinForms does what I need when I need a GUI, which is rare.
|
|
|
|
|
Lots of good answers, and from my 4+ decades of experience as a professional developer (now retired), I suspect its a combination. So, allow me to weigh in with some of my own thoughts:
My experience includes Win16/Win32 APIs (C), MFC (C,C++), WinForms (C#) and WPF (C#, Framework and Core). While I agree with the sentiment that one must keep moving forward in a professional setting (i.e. clients as the end users), I also have endured the pain of being unable to upgrade because of client budget, incompatibilities, and developer culture.
In addition, much of the move from C/C++ to .NET and across GUI platforms was made both easier and more difficult with COM, remoting, COM InterOp (RCWs/CCWs), as well as XML and JSON. When I was heavily invested in COM, I used WTL (Windows Template Library) for my GUIs when working in C++. WTL cannot replace MFC (it was never meant to), but for most applications it can hold it's own.
Here's the thing... I still love C/C++, it's often the only choice for me when I worked on embedded projects (think Eclipse IDE, etc.). That being said, C# is soooo much easier to work with, is in many ways more powerful and is as performant. That leaves me wondering why C/C++ for a Windows GUI project.
When it comes to which GUI platform in the C# world, WinForms "strength" is also it's weakness. If you have ever tried to implement components, or have to copy/reuse/resize a form and its subsequent components, you know how incredibly difficult that can be. Add in language support and it becomes a night mare.
On the other hand, WPF is indeed a steep learning curve, but what you trade for in return is extensibility and full theming and language support in XAML through control and data templates, styles, etc. Once you use and master WPF, there's no going back! 
One could punt and use WPF in a minimalist way by using a Grid control and just plop controls in fixed positions. One could avoid learning a large part of WPF, but that's like buying a Ferrari only to transport people around by dragging it behind a tow truck.
So I do get it's context dependent, such that there are still a great many developers that choose alternate paths. Sometimes there's no compelling reason when, for example, supporting a legacy application that no longer is viable to port or upgrade. I also do defend the right of hobbyists to pick their poison. I still love, now again, to fire up my Trash80, if for no other reason, than to see if ChatGPT ports to Z-80 really work!  
One group notably missing from those that responded are VB/VB.NET developers. It's very easy to take cheap shots at both, but I would think at least VB.NET would be a popular choice given its similarities to WinForms, and the fact that many of us cut our teeth on some form of interpreted BASIC on older vintage hardware. NewDOS, DOSPLus and LDOS (TRS-80 DOSs) all offered significant powerful features to BASIC, and I wrote and supported commercial application back in the 80s. While C++ and C# captured my heart years ago, I will always have a place in my heart for BASIC.
...and maybe assembly language, since the Z-80 and the 6502 were my first forays into learning to write software on the TRS-80 and Apple II/II Plus.
Well, that's my two shekels.
|
|
|
|
|
Stacy, being semi-retired (which has been a fail, lol) I think one of the reasons I've seen is that basically we're often assigned to build things and it's not worth the learning curve to accomplish the given task. So, the default is using the tools you know.
I live in my odd world of C#/VB .NET, PHP, and JS along with some of its variants. One project is an 'agile-RAD' large desktop app using WinForms and VB.net. There's no budget to recode in C# or anything else, and no real reason to do so since there's no scalability requirement; the number of users will never be greater than a few dozen. Their needs change regularly with quick implementation required. Their apps are heavily data-driven pulling from Postgres and DB changes aren't unusual. The datagridview control is a staple for their needs, which has both pros and cons to its WPF counterpart.
Oops, back to your question. If someone asked me for a desktop app today from scratch, it would be in VS; likely C# but I wouldn't totally rule out VB depending on the specs. I know there's differences, but for a lot of things they can be negligible. Winforms vs WPF is a deeper design consideration. In truth today, it's rare to see a 'from scratch' app that doesn't have interaction with either existing DBs, the web or some other requirements. I use more contract work where required in some cases to maintain sanity.
Though... I'm working on a project that has a large PHP codebase and a proposed new piece requires it to play nice with a Node-JS API app. My colleague of 30 years told me that "I'm crossing over to the dark side". 
|
|
|
|
|
Stacy Dudovitz wrote: One group notably missing from those that responded are VB/VB.NET developers. It's very easy to take cheap shots at both, but I would think at least VB.NET would be a popular choice given its similarities to WinForms, and the fact that many of us cut our teeth on some form of interpreted BASIC on older vintage hardware.
About 75% of my work assignments in the 90's were VB (v2 through v6), and it was THE way to produce solid business applications for Windows quickly. Friends who worked in other technologies looked down upon VB, but I was producing in 3 months what they were taking a year+ to do. And I had my pick of assignments there was so much work.
Fast forward to 2003 -- VB.NET had been out 2 years and VB6 work was slowing down. I had ridden the bleeding edge since graduation, so I jumped on the VB.NET bandwagon, assuming it was the logical progression.
It wasn't. There was no progression, it was a BASIC-like language that had nothing to do with Visual Basic. MS published an "upgrade wizard" ...  anyone who tried it knows how well it [didn't] work.
After a year or so, I switched to C#, as it was getting solid support from MS AND there was a good job market. It's been 20 years and I do not regret that decision. The skillset has kept me employed and will do so until I retire. Yes, I keep up with other technologies and if there's a downturn in the C# market, I'll jump ship.
WinForms is the follow-on to what made VB so useful. It works and works well -- if developing Windows desktop applications. With the Click-Once installers, we deploy to SharePoint and our installation problems are about 5% of what they are in other technologies.
Regarding CORE and new C# versions?
Both change way too quickly for business needs, and a lot of what's released is not necessary or useful to folks whose primary job is solving business problems quickly and efficiently.
|
|
|
|
|
Brilliant post. (VB is an odd duck; it's component based; not object oriented; but it gained my interest in components that I fashion extensively to this day).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
WPF was the last product of the Old Microsoft. It has a steep learning curve, it's purpose is to make a Windows application not looking like a Windows application (formerly known as skinning), so it is not really for LoB apps.
The Cool Kids on the Code Block developed MVVM for it, which is a method to disrupt the normal way of the flow of information between the GUI and the backend (see validation), so it is not really for LoB apps.
Everything beyond that is just the usual dumbing down of Windows to the UNIX/Machintos level.
|
|
|
|
|
About the bonus question:
There are better platforms for VB6, for example VBForums.
There are probably only a few questions for VB.Net syntax. Framework questions can also be answered via C# answers. That's how I do it.
|
|
|
|
|
A bunch of reasons:
1) In most cases WPF doesn't solve anything that WinForm can't solve. The amount of customizations and pipelines that you can make with WPF are useful on large interconnected desktop applications - which aren't many;
2) WPF and .NET documentation sucks terribly. It's a giant reference manual without any explanations on how the various pieces should be glued together. This situation is improving, too slowly.
3) WPF does not support native development, WinForms supports both native and .NET. It wins.
4) WPF is simple. Most of the time the real work is behind the scenes and you really need a UI only to interact, briefly, with the backend. The tool I'm maintaining to flash and operate on the equipment manifactured by my company for example would not benefit from the additional complexity of WPF: we need a bunch of buttons, a bunch of textboxes and some radio button or combobox, and the occasional slider.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
