Impressions of WPF
-
Well I've started working with WPF again, seriously this time, after just a bit of fiddling before, and I must say I'm not terribly impressed. My initial reaction was similar, and it hasn't improved. It seems to be extremely complicated to do a simple thing, unless the designers took explicit steps to make a certain thing easy. It's just not inherently simple, and I don't like that. Programming in xml is a pain to put it lightly. XML was never meant to be hand-coded, or if it was, they did a very poor job of it. Human-readable, yes, human-writable? Not likely. It's a horrible syntax to write in. Just for example (and maybe some WPF whiz can prove me wrong on these), it seems darn near impossible to think abstractly when designing in WPF, and abstraction is how I operate. Everything in WPF is concrete, as if we were molding an interface out of clay. When you want to attach a ContextMenu to an object, WPF expects you to define the whole menu right inside that object! What if I want to use the same menu for several things, or worse yet, what if I want the menu to be dynamically generated? These things may be possible, but they sure as hell aren't intuitive. I couldn't even find the answer looking at menu tutorials because they all embed them at the source! Furthermore, things like icons and tool tips are also embedded right in the menu--whatever happened to separation of data/logic from presentation? Everything in WPF is stuck in one place. Next, the x:Name thing is lame. Sometimes you can't attach what you want directly to the object, so you have to name it, and reference it elsewhere. Where? In some other block in the same big xaml file. I want modularity. I'm only getting started here. The syntax for things like resources and binding is horrendous. I've already read a whole book on WPF and I can't remember any of it. Why? Because it doesn't make any sense. The communication back and forth from a xaml file and C# file is very limited. How do I access an object in C# that I declare in xaml? The point is, xml and C# don't mix. MS should have chosen a better way to code in WPF. I'm still trying to figure all this out, but I just needed to get this off my chest. Maybe my opinion will improve over time. I hope so. :|
“Time and space can be a bitch.” –Gushie, Quantum Leap {o,o}.oO( Looking for a great RSS reader? Try FeedBeast! ) |)””’) &nb
-
Well I've started working with WPF again, seriously this time, after just a bit of fiddling before, and I must say I'm not terribly impressed. My initial reaction was similar, and it hasn't improved. It seems to be extremely complicated to do a simple thing, unless the designers took explicit steps to make a certain thing easy. It's just not inherently simple, and I don't like that. Programming in xml is a pain to put it lightly. XML was never meant to be hand-coded, or if it was, they did a very poor job of it. Human-readable, yes, human-writable? Not likely. It's a horrible syntax to write in. Just for example (and maybe some WPF whiz can prove me wrong on these), it seems darn near impossible to think abstractly when designing in WPF, and abstraction is how I operate. Everything in WPF is concrete, as if we were molding an interface out of clay. When you want to attach a ContextMenu to an object, WPF expects you to define the whole menu right inside that object! What if I want to use the same menu for several things, or worse yet, what if I want the menu to be dynamically generated? These things may be possible, but they sure as hell aren't intuitive. I couldn't even find the answer looking at menu tutorials because they all embed them at the source! Furthermore, things like icons and tool tips are also embedded right in the menu--whatever happened to separation of data/logic from presentation? Everything in WPF is stuck in one place. Next, the x:Name thing is lame. Sometimes you can't attach what you want directly to the object, so you have to name it, and reference it elsewhere. Where? In some other block in the same big xaml file. I want modularity. I'm only getting started here. The syntax for things like resources and binding is horrendous. I've already read a whole book on WPF and I can't remember any of it. Why? Because it doesn't make any sense. The communication back and forth from a xaml file and C# file is very limited. How do I access an object in C# that I declare in xaml? The point is, xml and C# don't mix. MS should have chosen a better way to code in WPF. I'm still trying to figure all this out, but I just needed to get this off my chest. Maybe my opinion will improve over time. I hope so. :|
“Time and space can be a bitch.” –Gushie, Quantum Leap {o,o}.oO( Looking for a great RSS reader? Try FeedBeast! ) |)””’) &nb
logan1337 wrote:
XML was never meant to be hand-coded
You can use Visual Studio to do this, but you're better off with Expression Blend.
logan1337 wrote:
Furthermore, things like icons and tool tips are also embedded right in the menu--whatever happened to separation of data/logic from presentation? Everything in WPF is stuck in one place.
Not true. The more you work with WPF, the more you learn about how to separate things out (have a read of Josh Smith's excellent articles, especially on MVVM). Also, you can take a look at the new Composite Application Guidance[^] for WPF.
logan1337 wrote:
The syntax for things like resources and binding is horrendous.
It does take some getting used to, but once you do it really starts to make sense. The big thing to remember about WPF is that binding goes so much further than it does in traditional WinForms apps, so you can bind to much more than just lists of data - you can bind to templates, controls and the like.
logan1337 wrote:
MS should have chosen a better way to code in WPF. I'm still trying to figure all this out, but I just needed to get this off my chest. Maybe my opinion will improve over time. I hope so.
When I started WPF, I read the Adam Nathan book and tried a few things and just couldn't get my head round it. One day, it all went click and then it made a lot of sense. As a hint - try approaching it with the mindset of developing an ASP.NET app - some of the concepts make more sense when you view it from that point of view.
Deja View - the feeling that you've seen this post before.
-
Well I've started working with WPF again, seriously this time, after just a bit of fiddling before, and I must say I'm not terribly impressed. My initial reaction was similar, and it hasn't improved. It seems to be extremely complicated to do a simple thing, unless the designers took explicit steps to make a certain thing easy. It's just not inherently simple, and I don't like that. Programming in xml is a pain to put it lightly. XML was never meant to be hand-coded, or if it was, they did a very poor job of it. Human-readable, yes, human-writable? Not likely. It's a horrible syntax to write in. Just for example (and maybe some WPF whiz can prove me wrong on these), it seems darn near impossible to think abstractly when designing in WPF, and abstraction is how I operate. Everything in WPF is concrete, as if we were molding an interface out of clay. When you want to attach a ContextMenu to an object, WPF expects you to define the whole menu right inside that object! What if I want to use the same menu for several things, or worse yet, what if I want the menu to be dynamically generated? These things may be possible, but they sure as hell aren't intuitive. I couldn't even find the answer looking at menu tutorials because they all embed them at the source! Furthermore, things like icons and tool tips are also embedded right in the menu--whatever happened to separation of data/logic from presentation? Everything in WPF is stuck in one place. Next, the x:Name thing is lame. Sometimes you can't attach what you want directly to the object, so you have to name it, and reference it elsewhere. Where? In some other block in the same big xaml file. I want modularity. I'm only getting started here. The syntax for things like resources and binding is horrendous. I've already read a whole book on WPF and I can't remember any of it. Why? Because it doesn't make any sense. The communication back and forth from a xaml file and C# file is very limited. How do I access an object in C# that I declare in xaml? The point is, xml and C# don't mix. MS should have chosen a better way to code in WPF. I'm still trying to figure all this out, but I just needed to get this off my chest. Maybe my opinion will improve over time. I hope so. :|
“Time and space can be a bitch.” –Gushie, Quantum Leap {o,o}.oO( Looking for a great RSS reader? Try FeedBeast! ) |)””’) &nb
I felt the same way last year. It takes a while before you get an "ah-ha" moment and then it starts to click. There's a lot to it so it's constantly a learning experience. If you want to really get frustrated, try Xbap. I'm hitting walls because of the security sandbox, but that's my own fault for not focusing on the boundaries like I should have.
logan1337 wrote:
XML was never meant to be hand-coded, or if it was, they did a very poor job of it. Human-readable, yes, human-writable? Not likely. It's a horrible syntax to write in.
It's similar to hand coding HTML. I started off using Xaml visual designers and now I'm mostly hand coding Xaml, mostly because I'd rather learn Xaml than learn how to use a designer (like Expression Blend) aimed at graphics people. The visual designer in VS2008 sucks.
logan1337 wrote:
WPF expects you to define the whole menu right inside that object! What if I want to use the same menu for several things, or worse yet, what if I want the menu to be dynamically generated?
Declare it as a resource, give it a key:
<ContextMenu x:Key="MainContextMenu">
<MenuItem Header="File"/>
<MenuItem Header="Save"/>
<enuItem Header="SaveAs"/>
</ContextMenu>Access it with ContextMenu="{StaticResource MainContextMenu}". Now you can attach it to any object that needs it.
logan1337 wrote:
Maybe my opinion will improve over time.
It takes a change of mindset and a lot of patience. I prefer it to winforms now but I only know maybe 10% of it's capabilities. It's definitely something that takes time. Some of the great WPF guys on this board have been at it for a year or two and are still learning.
-
I felt the same way last year. It takes a while before you get an "ah-ha" moment and then it starts to click. There's a lot to it so it's constantly a learning experience. If you want to really get frustrated, try Xbap. I'm hitting walls because of the security sandbox, but that's my own fault for not focusing on the boundaries like I should have.
logan1337 wrote:
XML was never meant to be hand-coded, or if it was, they did a very poor job of it. Human-readable, yes, human-writable? Not likely. It's a horrible syntax to write in.
It's similar to hand coding HTML. I started off using Xaml visual designers and now I'm mostly hand coding Xaml, mostly because I'd rather learn Xaml than learn how to use a designer (like Expression Blend) aimed at graphics people. The visual designer in VS2008 sucks.
logan1337 wrote:
WPF expects you to define the whole menu right inside that object! What if I want to use the same menu for several things, or worse yet, what if I want the menu to be dynamically generated?
Declare it as a resource, give it a key:
<ContextMenu x:Key="MainContextMenu">
<MenuItem Header="File"/>
<MenuItem Header="Save"/>
<enuItem Header="SaveAs"/>
</ContextMenu>Access it with ContextMenu="{StaticResource MainContextMenu}". Now you can attach it to any object that needs it.
logan1337 wrote:
Maybe my opinion will improve over time.
It takes a change of mindset and a lot of patience. I prefer it to winforms now but I only know maybe 10% of it's capabilities. It's definitely something that takes time. Some of the great WPF guys on this board have been at it for a year or two and are still learning.
Thanks for the tips--I will refrain from posting any followup questions in the lounge. It's good to know at least it is possible--I was thinking that resources might be the way to do it, but it still seems odd to me.
“Time and space can be a bitch.” –Gushie, Quantum Leap {o,o}.oO( Looking for a great RSS reader? Try FeedBeast! ) |)””’) Built with home-grown CodeProject components! -”-”-
-
logan1337 wrote:
XML was never meant to be hand-coded
You can use Visual Studio to do this, but you're better off with Expression Blend.
logan1337 wrote:
Furthermore, things like icons and tool tips are also embedded right in the menu--whatever happened to separation of data/logic from presentation? Everything in WPF is stuck in one place.
Not true. The more you work with WPF, the more you learn about how to separate things out (have a read of Josh Smith's excellent articles, especially on MVVM). Also, you can take a look at the new Composite Application Guidance[^] for WPF.
logan1337 wrote:
The syntax for things like resources and binding is horrendous.
It does take some getting used to, but once you do it really starts to make sense. The big thing to remember about WPF is that binding goes so much further than it does in traditional WinForms apps, so you can bind to much more than just lists of data - you can bind to templates, controls and the like.
logan1337 wrote:
MS should have chosen a better way to code in WPF. I'm still trying to figure all this out, but I just needed to get this off my chest. Maybe my opinion will improve over time. I hope so.
When I started WPF, I read the Adam Nathan book and tried a few things and just couldn't get my head round it. One day, it all went click and then it made a lot of sense. As a hint - try approaching it with the mindset of developing an ASP.NET app - some of the concepts make more sense when you view it from that point of view.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
but you're better off with Expression Blend.
But how many of us can afford to pay for it?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
