WPF - why?!
-
Granted - I saw some very nice looking ones... But! If you put a DataGrid on a form and bind it to some data, plus add some buttons to each row (template)... It looks awful...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
-
Granted - I saw some very nice looking ones... But! If you put a DataGrid on a form and bind it to some data, plus add some buttons to each row (template)... It looks awful...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
-
So I have to write a new extension for VS, which means I have to deal with WPF... DataGrid in this case... Why's that WPF, that came to life to replace the ugly WinForms, is so ugly?
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
Kornfeld Eliyahu Peter wrote:
Why's that WPF, that came to life to replace the ugly WinForms, is so ugly?
Because they decided instead to focus on an inane XML syntax instead that requires, among other things, custom instantiators instead of a simple parser and is almost (if not completely) impossible to express and correctly render in a designer, requiring you to hand code the XML, which when I wrote my articles on MyXaml, everyone screeched about how nobody would want to hand-code XML to design a UI, but when Microsoft put out WPF, that's what everyone was forced to do and even seemed to enjoy doing. Um.. end rant? Oh, and because Microsoft likes to leave the professional UI design to third parties. :)
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Kornfeld Eliyahu Peter wrote:
Why's that WPF, that came to life to replace the ugly WinForms, is so ugly?
Because they decided instead to focus on an inane XML syntax instead that requires, among other things, custom instantiators instead of a simple parser and is almost (if not completely) impossible to express and correctly render in a designer, requiring you to hand code the XML, which when I wrote my articles on MyXaml, everyone screeched about how nobody would want to hand-code XML to design a UI, but when Microsoft put out WPF, that's what everyone was forced to do and even seemed to enjoy doing. Um.. end rant? Oh, and because Microsoft likes to leave the professional UI design to third parties. :)
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Marc Clifton wrote:
professional UI design
Don't go that far... I would like - for start - that vertical alignment in DataGrid of the content would be logical (bottom for all RTL and LTR languages)... It is not that professional level request...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
-
Jacquers wrote:
you can make some really nice looking apps.
...if you're willing to allocate the resources to do it. Otherwise WPF apps can be made to look every bit as ugly as WinForms-based apps. If your focus is not on the UI, then WPF adds a lot of cost (in terms of learning overhead) with very little return, IMO.
-
So I have to write a new extension for VS, which means I have to deal with WPF... DataGrid in this case... Why's that WPF, that came to life to replace the ugly WinForms, is so ugly?
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
Why do you need to write an extension in the first place? . There are third party grid components like xceed that can make life easier...anyway..
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
Why do you need to write an extension in the first place? . There are third party grid components like xceed that can make life easier...anyway..
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
A Visual Studio Extension...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
-
A Visual Studio Extension...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
-
To do what..
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
Metadata management for our development...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
-
Metadata management for our development...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
so got custom "metadata" in your code and you need a to develop a gui that will display the "metadata" in a datagrid in visual studio when a dev click a button in vs..
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
I know what you mean ... it's like they had a good idea but it never really got finished. With a good intelligent design UI it could have been so good. As it is it's too clumsy and just feels unfinished to develop in. Pity.
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Agreed. The framework incorporates some really great ideas and then falls flat in the implementation. My biggest complaint (vs WinForm) is that the design UI completely sucks by comparison. In VS, with WinForm, everything is drag-and-drop / point-and-click. With WPF, I need to constantly resort to editing the XML. There is no reason it needs to be this way. They really need to either get a better UI team or give the team they already have time to fix it. The other problem is the (effective) lack of immediate-mode graphics. I understand that for line-of-business apps this makes perfect sense. However, they should support a fall-back for graphic intensive applications. Try drawing and re-drawing a few thousand lines. Performance is fine in WinForm, but its frustratingly slow in WPF...even when you take advantage of all the WPF performance tweaks. To solve this performance issue, we're left playing with 3rd party work-arounds...using writeable bitmaps. They work great. This means there is absolutely no reason, other than arrogance, that MS can't incorporate some of these concepts into WPF...in a better supported/more seamless fashion. Also, provide better support for WinForm-style docking. Yes, I understand the other layouts are far more flexible and worth learning. I took the time. I still find them less intuitive. So, why punish WinForm developers making the transition? Keep the cool new layouts and add better support for docking layouts as well. As it stands now, for me, WPF is an interesting toy for occasional play. I use it when I want some really flexible layouts...in line-of-business apps. Or, when a customer requests it. Or, when I play with UWP. Otherwise, I still use WinForm. Its a real shame. I'd prefer to move full time to WPF, to ease the wear-and-tear switching back and forth causes on my poor brain. Come on MS...finish what you started!
-
So I have to write a new extension for VS, which means I have to deal with WPF... DataGrid in this case... Why's that WPF, that came to life to replace the ugly WinForms, is so ugly?
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
Kornfeld Eliyahu Peter wrote:
ugly WinForms
I imagine the original design goals to include things like functionality, accessability, discoverabilty and consistency. Not "look sexy".
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Agreed. The framework incorporates some really great ideas and then falls flat in the implementation. My biggest complaint (vs WinForm) is that the design UI completely sucks by comparison. In VS, with WinForm, everything is drag-and-drop / point-and-click. With WPF, I need to constantly resort to editing the XML. There is no reason it needs to be this way. They really need to either get a better UI team or give the team they already have time to fix it. The other problem is the (effective) lack of immediate-mode graphics. I understand that for line-of-business apps this makes perfect sense. However, they should support a fall-back for graphic intensive applications. Try drawing and re-drawing a few thousand lines. Performance is fine in WinForm, but its frustratingly slow in WPF...even when you take advantage of all the WPF performance tweaks. To solve this performance issue, we're left playing with 3rd party work-arounds...using writeable bitmaps. They work great. This means there is absolutely no reason, other than arrogance, that MS can't incorporate some of these concepts into WPF...in a better supported/more seamless fashion. Also, provide better support for WinForm-style docking. Yes, I understand the other layouts are far more flexible and worth learning. I took the time. I still find them less intuitive. So, why punish WinForm developers making the transition? Keep the cool new layouts and add better support for docking layouts as well. As it stands now, for me, WPF is an interesting toy for occasional play. I use it when I want some really flexible layouts...in line-of-business apps. Or, when a customer requests it. Or, when I play with UWP. Otherwise, I still use WinForm. Its a real shame. I'd prefer to move full time to WPF, to ease the wear-and-tear switching back and forth causes on my poor brain. Come on MS...finish what you started!
Eric Lynch wrote:
I need to constantly resort to editing the XML
XAML - I was full time in WPF and have never used drag and drop to get controls on a view :^) I had forgotten how easy winforms UI layout is. Thankfully I have never been into graphics, purely LOB work and I still run up against performance issues.
Never underestimate the power of human stupidity RAH
-
Granted - I saw some very nice looking ones... But! If you put a DataGrid on a form and bind it to some data, plus add some buttons to each row (template)... It looks awful...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
Kornfeld Eliyahu Peter wrote:
plus add some buttons to each row
Ah thinking like a web developer, I cannot remember when I last had buttons on each row. My VM knows precisely what row is selected so all I need is the action directive, also double click is your friend.
Never underestimate the power of human stupidity RAH
-
Granted - I saw some very nice looking ones... But! If you put a DataGrid on a form and bind it to some data, plus add some buttons to each row (template)... It looks awful...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
-
Jacquers wrote:
you can make some really nice looking apps.
...if you're willing to allocate the resources to do it. Otherwise WPF apps can be made to look every bit as ugly as WinForms-based apps. If your focus is not on the UI, then WPF adds a lot of cost (in terms of learning overhead) with very little return, IMO.
-
Agreed. The framework incorporates some really great ideas and then falls flat in the implementation. My biggest complaint (vs WinForm) is that the design UI completely sucks by comparison. In VS, with WinForm, everything is drag-and-drop / point-and-click. With WPF, I need to constantly resort to editing the XML. There is no reason it needs to be this way. They really need to either get a better UI team or give the team they already have time to fix it. The other problem is the (effective) lack of immediate-mode graphics. I understand that for line-of-business apps this makes perfect sense. However, they should support a fall-back for graphic intensive applications. Try drawing and re-drawing a few thousand lines. Performance is fine in WinForm, but its frustratingly slow in WPF...even when you take advantage of all the WPF performance tweaks. To solve this performance issue, we're left playing with 3rd party work-arounds...using writeable bitmaps. They work great. This means there is absolutely no reason, other than arrogance, that MS can't incorporate some of these concepts into WPF...in a better supported/more seamless fashion. Also, provide better support for WinForm-style docking. Yes, I understand the other layouts are far more flexible and worth learning. I took the time. I still find them less intuitive. So, why punish WinForm developers making the transition? Keep the cool new layouts and add better support for docking layouts as well. As it stands now, for me, WPF is an interesting toy for occasional play. I use it when I want some really flexible layouts...in line-of-business apps. Or, when a customer requests it. Or, when I play with UWP. Otherwise, I still use WinForm. Its a real shame. I'd prefer to move full time to WPF, to ease the wear-and-tear switching back and forth causes on my poor brain. Come on MS...finish what you started!
I've never used the UI designer, and do everything in XAML. Even Blend still scares the hell out of me to this day, and I'm a proficient WPF/XAML developer. Writing XAML is no different to a web developer writing HTML - nobody uses drag'n'drop interfaces on that platform. Admittedly it's easier to see your changes by just pressing F5 in the open browser window, rather than have to run the app...
-
Agreed. The framework incorporates some really great ideas and then falls flat in the implementation. My biggest complaint (vs WinForm) is that the design UI completely sucks by comparison. In VS, with WinForm, everything is drag-and-drop / point-and-click. With WPF, I need to constantly resort to editing the XML. There is no reason it needs to be this way. They really need to either get a better UI team or give the team they already have time to fix it. The other problem is the (effective) lack of immediate-mode graphics. I understand that for line-of-business apps this makes perfect sense. However, they should support a fall-back for graphic intensive applications. Try drawing and re-drawing a few thousand lines. Performance is fine in WinForm, but its frustratingly slow in WPF...even when you take advantage of all the WPF performance tweaks. To solve this performance issue, we're left playing with 3rd party work-arounds...using writeable bitmaps. They work great. This means there is absolutely no reason, other than arrogance, that MS can't incorporate some of these concepts into WPF...in a better supported/more seamless fashion. Also, provide better support for WinForm-style docking. Yes, I understand the other layouts are far more flexible and worth learning. I took the time. I still find them less intuitive. So, why punish WinForm developers making the transition? Keep the cool new layouts and add better support for docking layouts as well. As it stands now, for me, WPF is an interesting toy for occasional play. I use it when I want some really flexible layouts...in line-of-business apps. Or, when a customer requests it. Or, when I play with UWP. Otherwise, I still use WinForm. Its a real shame. I'd prefer to move full time to WPF, to ease the wear-and-tear switching back and forth causes on my poor brain. Come on MS...finish what you started!
I'm currently working on a graphics intensive application as well. Redrawing using WPF took about 7 seconds. We're currently using a SharpDX based renderer instead and when we need to update ALL the primitives and redraw it takes about 25ms. WPF is based on Dx9(and needs to be updated to 12 tbh) so it shouldn't need to be this freaking slow!
-
So I have to write a new extension for VS, which means I have to deal with WPF... DataGrid in this case... Why's that WPF, that came to life to replace the ugly WinForms, is so ugly?
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
The (wpf) UI designer is definitely horrible. And wpf does have a steeeep learning curve (trust me, 'been there). The funny thing is, to fully appreciate it, you need to use it (and actually compare it to Winforms) - and while at the beginning, you'll curse a lot (I did :D), when you start to "get" it, you'll use it for any non-trivial UI. The more you'll delve into it, the more you'll love it (granted, you'll still hate the UI designer :D). Two easy examples: animations, pixel shaders (i.e., Effects). When you actually start understanding how layout works in wpf, you'll be able to create controls that can simply blow your mind (which would be really really hard to implement in Winforms)! Best, John P.S. If (just if :D) you want to learn WPF, I recommend "WPF 4.5 Unleashed" - a lot of things don't seem to make any sense in WPF, until explained. Again, been there :)
-- Phot-Awe - Find the Photos you Love - FAST!
-
So I have to write a new extension for VS, which means I have to deal with WPF... DataGrid in this case... Why's that WPF, that came to life to replace the ugly WinForms, is so ugly?
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
Winforms isn't ugly in my opinion. WPF is, though! :doh:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain