WPF Rant
-
I know I'm late to this game, but ..... WPF WTF? X| An impenetrable object model... X| A million-and-one different ways to do everything... X| Brings all the horrors of CSS to application development... X| I'm waiting to see some advantage... :mad: Thank-you! :)
I recommend Pro WPF 4.5 in C#[^] by Matthew MacDonald. I used an earlier edition to learn WPF, and it helped a lot.
Software Zen:
delete this; -
I know I'm late to this game, but ..... WPF WTF? X| An impenetrable object model... X| A million-and-one different ways to do everything... X| Brings all the horrors of CSS to application development... X| I'm waiting to see some advantage... :mad: Thank-you! :)
IMO - Don't start with how it should look - start with what it should do and let that drive how it should look. (It is still hard work but a bit less so)
-
If you have a copy of Visual Studio 2010 handy, you could check out MVVM in the Box and the accompanying video, helps WPF go down a little easier!
Well fads they come and fads they go. And God I love that rock and roll! Well the point was fast but it was too blunt to miss. Life handed us a paycheck, we said, "We worked harder than this!"
-
IMO - Don't start with how it should look - start with what it should do and let that drive how it should look. (It is still hard work but a bit less so)
-
I know I'm late to this game, but ..... WPF WTF? X| An impenetrable object model... X| A million-and-one different ways to do everything... X| Brings all the horrors of CSS to application development... X| I'm waiting to see some advantage... :mad: Thank-you! :)
WPF is pretty cool. I will agree that it has flaws, and the lack of 'dispose' methods on objects is certainly one of them. But, having videos and other UI elements all on the same canvas is a huge advantage in some applications.
Christian Graus My new article series is all about SQL !!!
-
:rolleyes: Sorry I had to laugh at this reply! Unfortunately, the project I'm working on is used to produce a user-configurable graphic for use elsewhere. It doesn't "do" anything, and is in fact all about how it should look! :rolleyes:
I do LOB in Silverloght (WPFs little brother for the web) and have to now look at MVC with all it's attendant tools (CSS, javascript, knockout, bootstrap, kendo etc). Makes WPF seem simple. Mind you I consider graphics development the most difficult and would not even attempt what you are learning on, give me business data any day!
Never underestimate the power of human stupidity RAH
-
I know I'm late to this game, but ..... WPF WTF? X| An impenetrable object model... X| A million-and-one different ways to do everything... X| Brings all the horrors of CSS to application development... X| I'm waiting to see some advantage... :mad: Thank-you! :)
Kyudos wrote:
I'm waiting to see some advantage...
I'm waiting for it to go away. Marc
-
I know I'm late to this game, but ..... WPF WTF? X| An impenetrable object model... X| A million-and-one different ways to do everything... X| Brings all the horrors of CSS to application development... X| I'm waiting to see some advantage... :mad: Thank-you! :)
The results available with WPF can be great. The way to achieve those results is a pain in the backside. When someone develops a GUI tool to effectively edit XAML it will be a vast improvement. Personally I don't think that is now ever going to happen and Xaml will eventually die.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
The results available with WPF can be great. The way to achieve those results is a pain in the backside. When someone develops a GUI tool to effectively edit XAML it will be a vast improvement. Personally I don't think that is now ever going to happen and Xaml will eventually die.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
I know I'm late to this game, but ..... WPF WTF? X| An impenetrable object model... X| A million-and-one different ways to do everything... X| Brings all the horrors of CSS to application development... X| I'm waiting to see some advantage... :mad: Thank-you! :)
I'm not sure what you mean with bringing CSS horrors to application development? I love xaml / C# combo. :-) It's indeed a steap learning curve though. Once you understand the magic, I feel like it's super easy (and fast) to get stuff going on screen. MVVM is a must, though.
-
I know I'm late to this game, but ..... WPF WTF? X| An impenetrable object model... X| A million-and-one different ways to do everything... X| Brings all the horrors of CSS to application development... X| I'm waiting to see some advantage... :mad: Thank-you! :)
I have been working with WPF for something like 7 years, and I still go through times when I wonder if it is insane, or insanely beautiful. I usually conclude that it is a bit of both. Often it takes a lot of work and verbosity and debugging to hook something up in XAML and have clean separation when it could be done with a bit of C#, but doing things declaratively is a bit of a game. It can be fun to learn, but sometimes it just isn't worth it to achieve the separation between code and layout. It is an addictive game, though, that pulls you in deeper and deeper. At some point along the way it clicked, and I started breathing Styles, triggers, attached properties, DataTemplates, ControlTemplates, Bindings, RelativeSources, CollectionViewSources, StaticResources, DynamicResources, TemplateBindings, BooleanToVisibilityConverters, custom IValueConverters, DoubleAnimations, LinearGradientBrushes, Grid.ColumnDefitions, TransformGroups, AffectsRender, Storyboards, oh my! "I don't often" enjoy writing XML, but when I do, it's XAML. I never used Blend, doing most by hand in Visual Studio, with its Intellisense that reads your mind, letting you avoid writing the bulk of the actual XAML. (I'm stuck with VS 2012 when editing XAML, since for some reason 2013's XAML editor crashes on my stuff by running out of virtual memory and I'm not alone.) For newbies, I definitely recommend learning via the top MVVM frameworks and/or books, and keeping references like http://wpftutorial.net/[^] handy, as WPF has a uniquely obtuse learning curve. I like to learn things by getting my hands dirty and diving in, but for this, take the time to learn some of the theory from someone who knows how to present the concepts in an easy to manage order. Also when you delve into bindings and collections, check out Bea Stollnitz's blog[^]http://www.zagstudio.com/blog[^]. She is some kind of superhuman that invented and can explain the bindings. Also, browse WPF articles here on codeproject, so you can see all the cool things that can be done. When WPF is my favorite thing, CodeProject becomes my favorite site. (And if I get stuck, stackoverflow is my go to.) I also
-
The results available with WPF can be great. The way to achieve those results is a pain in the backside. When someone develops a GUI tool to effectively edit XAML it will be a vast improvement. Personally I don't think that is now ever going to happen and Xaml will eventually die.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
What are you missing in the XAML editor? I prefer to write XAML instead of using the designer and I think it is faster than doing the same with WinForms in the WinForms designer. I can't see the "ridiculous verbosity of XAML". You write the properties which you would set in the property window for WinForms. If you have a look at the generated WinForms code, that is ridiculous verbosity.
-
What are you missing in the XAML editor? I prefer to write XAML instead of using the designer and I think it is faster than doing the same with WinForms in the WinForms designer. I can't see the "ridiculous verbosity of XAML". You write the properties which you would set in the property window for WinForms. If you have a look at the generated WinForms code, that is ridiculous verbosity.
Obviously writing Xaml is faster than writing Winforms purely in code - but thee designer for Winforms works and works reasonably well. The designer for Xaml is slow, buggy, crashes frequently, caches some stuff that require a restart of VS to fix, doesn't handle some things at all - so you need to resort to editing Xaml. Now for a simple form with a few controls, that's all good. For a complex control with many many panels, grids, lists etc. changing the layout is a nightmare - just negotiating the Xaml can be a nightmare because VS2010 takes so damn long to parse the Xaml (even when not displaying the view) that one loses the will to live waiting for it!
Christian Wulff wrote:
ridiculous verbosity of XAML
It wasn't me that said it - but I can see what people mean. it is verbose. Sure you only set the same properties you would by using the forms designer and setting properties - but again the designer lets you down by making it necessary to hand-write much of it rather than using a good tool to save you mucking up the level of curly braces etc.
Christian Wulff wrote:
If you have a look at the generated WinForms code, that is ridiculous verbosity.
Absolutely. But, then, you don't need to because the designer works.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
I have been working with WPF for something like 7 years, and I still go through times when I wonder if it is insane, or insanely beautiful. I usually conclude that it is a bit of both. Often it takes a lot of work and verbosity and debugging to hook something up in XAML and have clean separation when it could be done with a bit of C#, but doing things declaratively is a bit of a game. It can be fun to learn, but sometimes it just isn't worth it to achieve the separation between code and layout. It is an addictive game, though, that pulls you in deeper and deeper. At some point along the way it clicked, and I started breathing Styles, triggers, attached properties, DataTemplates, ControlTemplates, Bindings, RelativeSources, CollectionViewSources, StaticResources, DynamicResources, TemplateBindings, BooleanToVisibilityConverters, custom IValueConverters, DoubleAnimations, LinearGradientBrushes, Grid.ColumnDefitions, TransformGroups, AffectsRender, Storyboards, oh my! "I don't often" enjoy writing XML, but when I do, it's XAML. I never used Blend, doing most by hand in Visual Studio, with its Intellisense that reads your mind, letting you avoid writing the bulk of the actual XAML. (I'm stuck with VS 2012 when editing XAML, since for some reason 2013's XAML editor crashes on my stuff by running out of virtual memory and I'm not alone.) For newbies, I definitely recommend learning via the top MVVM frameworks and/or books, and keeping references like http://wpftutorial.net/[^] handy, as WPF has a uniquely obtuse learning curve. I like to learn things by getting my hands dirty and diving in, but for this, take the time to learn some of the theory from someone who knows how to present the concepts in an easy to manage order. Also when you delve into bindings and collections, check out Bea Stollnitz's blog[^]http://www.zagstudio.com/blog[^]. She is some kind of superhuman that invented and can explain the bindings. Also, browse WPF articles here on codeproject, so you can see all the cool things that can be done. When WPF is my favorite thing, CodeProject becomes my favorite site. (And if I get stuck, stackoverflow is my go to.) I also
-
I know I'm late to this game, but ..... WPF WTF? X| An impenetrable object model... X| A million-and-one different ways to do everything... X| Brings all the horrors of CSS to application development... X| I'm waiting to see some advantage... :mad: Thank-you! :)
I am in no position to answer your question, but when WPF was new I looked into it. It looked great and for a time i got very excited about it, but I never had the time to study it and in the end I decided that it wouldn't let me do anything I wanted to do that I couldn't do already. I'm sure I am wrong, there must be advantages. As for 'impenetrability', well that doesn't surprise me. I always find MS logic somewhat odd, though there can be no doubt as to the usefulness of their products in some situations.
-
I have been working with WPF for something like 7 years, and I still go through times when I wonder if it is insane, or insanely beautiful. I usually conclude that it is a bit of both. Often it takes a lot of work and verbosity and debugging to hook something up in XAML and have clean separation when it could be done with a bit of C#, but doing things declaratively is a bit of a game. It can be fun to learn, but sometimes it just isn't worth it to achieve the separation between code and layout. It is an addictive game, though, that pulls you in deeper and deeper. At some point along the way it clicked, and I started breathing Styles, triggers, attached properties, DataTemplates, ControlTemplates, Bindings, RelativeSources, CollectionViewSources, StaticResources, DynamicResources, TemplateBindings, BooleanToVisibilityConverters, custom IValueConverters, DoubleAnimations, LinearGradientBrushes, Grid.ColumnDefitions, TransformGroups, AffectsRender, Storyboards, oh my! "I don't often" enjoy writing XML, but when I do, it's XAML. I never used Blend, doing most by hand in Visual Studio, with its Intellisense that reads your mind, letting you avoid writing the bulk of the actual XAML. (I'm stuck with VS 2012 when editing XAML, since for some reason 2013's XAML editor crashes on my stuff by running out of virtual memory and I'm not alone.) For newbies, I definitely recommend learning via the top MVVM frameworks and/or books, and keeping references like http://wpftutorial.net/[^] handy, as WPF has a uniquely obtuse learning curve. I like to learn things by getting my hands dirty and diving in, but for this, take the time to learn some of the theory from someone who knows how to present the concepts in an easy to manage order. Also when you delve into bindings and collections, check out Bea Stollnitz's blog[^]http://www.zagstudio.com/blog[^]. She is some kind of superhuman that invented and can explain the bindings. Also, browse WPF articles here on codeproject, so you can see all the cool things that can be done. When WPF is my favorite thing, CodeProject becomes my favorite site. (And if I get stuck, stackoverflow is my go to.) I also
-
Obviously writing Xaml is faster than writing Winforms purely in code - but thee designer for Winforms works and works reasonably well. The designer for Xaml is slow, buggy, crashes frequently, caches some stuff that require a restart of VS to fix, doesn't handle some things at all - so you need to resort to editing Xaml. Now for a simple form with a few controls, that's all good. For a complex control with many many panels, grids, lists etc. changing the layout is a nightmare - just negotiating the Xaml can be a nightmare because VS2010 takes so damn long to parse the Xaml (even when not displaying the view) that one loses the will to live waiting for it!
Christian Wulff wrote:
ridiculous verbosity of XAML
It wasn't me that said it - but I can see what people mean. it is verbose. Sure you only set the same properties you would by using the forms designer and setting properties - but again the designer lets you down by making it necessary to hand-write much of it rather than using a good tool to save you mucking up the level of curly braces etc.
Christian Wulff wrote:
If you have a look at the generated WinForms code, that is ridiculous verbosity.
Absolutely. But, then, you don't need to because the designer works.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
_Maxxx_ wrote:
For a complex control with many many panels, grids, lists etc. changing the layout is a nightmare - just negotiating the Xaml can be a nightmare because VS2010 takes so damn long to parse the Xaml (even when not displaying the view) that one loses the will to live waiting for it!
My experience is that with MVVM, I don't have one complex control with many many panels, grids etc. because these are divided into some sub-controls. I choose to edit the XAML directly because for me it is easier that way and not because the designer is buggy. Same like I write HTML instead of using an HTML editor. But most of my WPF experience comes from VS 2012 and VS 2013, which are much faster and more responsive than VS 2010. I didn't want to start a religious war, just sharing my opinion that once I learned MVVM, I prefer WPF and XAML to WinForms and think it is easier :) Especially because I don't write much code-behind and don't need to subscribe to many control Events.
-
Obviously writing Xaml is faster than writing Winforms purely in code - but thee designer for Winforms works and works reasonably well. The designer for Xaml is slow, buggy, crashes frequently, caches some stuff that require a restart of VS to fix, doesn't handle some things at all - so you need to resort to editing Xaml. Now for a simple form with a few controls, that's all good. For a complex control with many many panels, grids, lists etc. changing the layout is a nightmare - just negotiating the Xaml can be a nightmare because VS2010 takes so damn long to parse the Xaml (even when not displaying the view) that one loses the will to live waiting for it!
Christian Wulff wrote:
ridiculous verbosity of XAML
It wasn't me that said it - but I can see what people mean. it is verbose. Sure you only set the same properties you would by using the forms designer and setting properties - but again the designer lets you down by making it necessary to hand-write much of it rather than using a good tool to save you mucking up the level of curly braces etc.
Christian Wulff wrote:
If you have a look at the generated WinForms code, that is ridiculous verbosity.
Absolutely. But, then, you don't need to because the designer works.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
Started reading this reply and I was thinking it sounds like this guy is still using 2010 or older. The new versions on studio have gotten much better at rendering xaml in the designer without crashing hanging etc. Between WinRT/Silverlight/WPF I rarely use or look at the designer, other than maybe once I am done to check my work. The designer generates horrible xaml anyway.
-
I am in no position to answer your question, but when WPF was new I looked into it. It looked great and for a time i got very excited about it, but I never had the time to study it and in the end I decided that it wouldn't let me do anything I wanted to do that I couldn't do already. I'm sure I am wrong, there must be advantages. As for 'impenetrability', well that doesn't surprise me. I always find MS logic somewhat odd, though there can be no doubt as to the usefulness of their products in some situations.
Technically assembler can do everything you need as well. Are you still using that? The power of xaml and therefore wpf, is that it is implemented in an incredibly consistent and logical fashion. Meaning that you can often predict where to do or find things in the xaml code even if you don't know what it is yet. I primarily contrast that to html which is the ultimate design by committee end product. There is a learning curve both for xaml and mvvm, but once over that curve you will be amazed at just how productive you can be.
-
I know I'm late to this game, but ..... WPF WTF? X| An impenetrable object model... X| A million-and-one different ways to do everything... X| Brings all the horrors of CSS to application development... X| I'm waiting to see some advantage... :mad: Thank-you! :)