Finally started doing some WPF...
-
Naerling wrote:
Any tips for a WinForms going WPF programmer?
- Forget everything you know about interfaces and design tiers. WPF is a completely different paradigm. 2) Learn to love XAML. It's weird and awkward at first, but once you get used to it, it's magic. 3) In a perfect world, your code-behind should NEVER* have to refer to a GUI control. Don't even assign names to your controls unless you need to refer to them from a trigger or storyboard. * There are, of course, unavoidable exceptions to this... Try to minimize them.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)You'll find it much easier if you think in terms of a model that the UI consumes. You'll want to do that anyway if you were to ever plan on sharing your business logic with other UIs, like Silverlight, MVC or (gasp) WebForms. That in itself takes some planning and forethought but it is possible. Your model knows nothing about UI elements, and your XAML code just binds to these properties on your model. Don't be afraid of having some code in your codebehind. I'm not in the camp that believes codebehind is evil, but if you're writing code that deals with business logic in codebehind you need to evaluate how that code goes into the model, and move it there. (Jumped into XAML a year ago and I'm never looking back.)
-
Started reading this huge book[^] (yes, VB and I'm proud of it! So don't start...) ;) Learning the "zammel" stuff, forgetting all I know about Events and Properties and thinking some very advanced controls are standard WPF stuff then finding out I have some DevExpress stuff installed... :doh: I've been planning this for months, and I finally started! Any tips for a WinForms going WPF programmer? (and no, I don't find this a programming question) :)
It's an OO world.
The most productive feature of XAML: COPY PASTE EDIT. I've found that ANYTHING I want to do in XAML is documented on a blog somewhere, COPY PASTE EDIT. You can't COPY PASTE EDIT a screenshot of a WinForm. Also, don't be afraid to use the designer to drag and drop buttons, labels, textboxes, etc. from the Toolbox. Visual Studio will autogenerate working XAML for you, and usually the only XAML you need to add by hand is the databindings. Then COPY PASTE EDIT this autogenerated XAML to create the rest of your controls.
-
May the force be with you... Everytime I go near WPF, I last about 30 minutes and say **** this! Maybe one day I will get past the hour mark (are there blue pills for WPF?). Hopefully, it will not end in :(( (well there might be a few to start with :sigh: )
Dave Find Me On: Web|Facebook|Twitter|LinkedIn
Folding Stats: Team CodeProject
I have found WPF to be much harder to master, but far more secure code wise. Following the MVVM pattern and using Galasoft MVVM Light toolkit was a huge help to me. When your code can't have bugs it's much easier to maintain. But I also see a lot more room for making sure you comment it well. With so much code in the ViewModel it is important to me to region it and comment it.
-
Started reading this huge book[^] (yes, VB and I'm proud of it! So don't start...) ;) Learning the "zammel" stuff, forgetting all I know about Events and Properties and thinking some very advanced controls are standard WPF stuff then finding out I have some DevExpress stuff installed... :doh: I've been planning this for months, and I finally started! Any tips for a WinForms going WPF programmer? (and no, I don't find this a programming question) :)
It's an OO world.
Sometimes; a Windows desktop app is just that: a Windows desktop app (e.g. SCADA). It’s not going to someday morph into a web app; or a “service” … So, just go ahead and have “fun with it”; and stop fretting about MVC, MVVM, blah, blah (for now). Learn to love the “Grid”; and grids within grids … and “Auto” versus “Star” rows and columns … and marvel at how all your controls will march to your tune (and never worry about absolute positioning / size again). Learn how to create User Controls and setting their data context to a single object; building complex UI’s out of one or more User Controls; “data templating” list items; implementing INotifyPropertyChanged and IDataErrorInfo. Think of application resources and property setters as another way of “styling” your UI elements from one convenient place. Use data triggers to collapse or show elements; or change color based on content. Learn what is meant by the “content model”; it is the key to making things look the way you want (e.g. a button with a picture). And ultimately, marvel at how new brain patterns are laid down and one actually “sees” the UI taking shape when working with pure XAML; to the point where one never bothers to use the designer.
-
Ian Shlasko wrote:
- Forget everything you know about interfaces and design tiers. WPF is a completely different paradigm.
- Learn to love XAML. It's weird and awkward at first, but once you get used to it, it's magic.
- In a perfect world, your code-behind should NEVER* have to refer to a GUI control. Don't even assign names to your controls unless you need to refer to them from a trigger or storyboard.
1. Forget that you are programmer. Now you are computer graphics maker/script writer. 2. Learn not to hate XAML. 3. Write more code and XAML than necessary. Make it more and more complicated. But never write code-behind. Real man doesn't write code-behind!
Alex Fr wrote:
- Learn to love XAML. It's weird
and awkward at first, but once you get used to it, it's magic.
I tried to get into WPF a couple of times and each time I was driven mad by the XAML bit. Coming from C++ and MFC, WinForms and C# seemed like a blessing when it came to making nice, functional interfaces. All (or at least most) of the properties for the components are in a nice properties box that you can modify to your hearts content. I don't really get why WPF seems to have gone backwards in usability by only having some properties exposed and everything else in the XAML, where you have to not only remember the name of the thing but also all of the properties. Don't get me wrong, I'm not trying to start an argument, I really just want someone to explain to me from a programming point of view, what makes WPF better than WinForms? Thanks Dave
-
Started reading this huge book[^] (yes, VB and I'm proud of it! So don't start...) ;) Learning the "zammel" stuff, forgetting all I know about Events and Properties and thinking some very advanced controls are standard WPF stuff then finding out I have some DevExpress stuff installed... :doh: I've been planning this for months, and I finally started! Any tips for a WinForms going WPF programmer? (and no, I don't find this a programming question) :)
It's an OO world.
Yeah, I have some tips. * Make something like Charles Petzold[^]'s XAML Cruncher. Well, try it, and then make your own. * Make a bunch of simple things with it before you bite off more than you can chew. It's really disappointing when you have this great idea for a GUI and then you drown in the XAML implementation because you didn't work through enough of the required ideas. * Read Sacha Barber's WPF articles[^] (scroll down to them.) His WPF code really sets a good standard. * Get yourself a copy of Expression Blend, if you can afford it. If you can't, at least get the express edition of Visual Studio for Windows Phone development, that has it. Then you can really play with these things in a GUI that was truly made for XAML development, and see how it all works. * Don't let this one scare you: It feels like a lower level than WinForms in some ways. You don't have to think about it often, but when you want to change the way it looks or feels, you'll get a good look at the guts. It has more guts than WinForms or MFC or anything else in @favorite_framework. Seriously. You'll have to think in terms of "What are the basic elements that compose this UI element" sometimes. Things as simple as a Button are made of borders and decorators and content presenters. A ScrollBar is broken down into its components. And just fuhgeddaboutit when you want to style a DataGrid until you've successfully styled less complex controls. Finally, don't listen to everything everyone tells you about it. Go, make things with it, and see for yourself how well it works for you.
-
Tip: use C#
I'd say: Understand C#. Most WPF samples are for C#. At least know enough so you can translate it to VB, if you really bet the farm on VB.
-
Started reading this huge book[^] (yes, VB and I'm proud of it! So don't start...) ;) Learning the "zammel" stuff, forgetting all I know about Events and Properties and thinking some very advanced controls are standard WPF stuff then finding out I have some DevExpress stuff installed... :doh: I've been planning this for months, and I finally started! Any tips for a WinForms going WPF programmer? (and no, I don't find this a programming question) :)
It's an OO world.
-
Ian Shlasko wrote:
- Forget everything you know about interfaces and design tiers. WPF is a completely different paradigm.
- Learn to love XAML. It's weird and awkward at first, but once you get used to it, it's magic.
- In a perfect world, your code-behind should NEVER* have to refer to a GUI control. Don't even assign names to your controls unless you need to refer to them from a trigger or storyboard.
1. Forget that you are programmer. Now you are computer graphics maker/script writer. 2. Learn not to hate XAML. 3. Write more code and XAML than necessary. Make it more and more complicated. But never write code-behind. Real man doesn't write code-behind!
-
Naerling wrote:
Any tips for a WinForms going WPF programmer? (and no, I don't find this a programming question)
- Do not, I repeat do not, go for the event programming model of Windows Form. 2) Always try and think about 'binding' properties.
Too much of heaven can bring you underground Heaven can always turn around Too much of heaven, our life is all hell bound Heaven, the kill that makes no sound
-
My one tip is check out this tiny component I wrote to make my life easier in WPF. I call it hip:Link: http://hip.codeplex.com/[^] It allows you to define a binding in terms of a method or property in the code-behind, so you don't need to do ungodly crap in your XAML or define custom converters for every single binding. It makes things significantly easier and is dead simple to use. Seriously I use it all the time. It's open sourced too.
Sad but true: 4/3 of Americans have difficulty with simple fractions. There are 10 types of people in this world: those who understand binary and those who don't. {o,o}.oO( Check out my blog! ) |)””’) http://pihole.org/ -”-”-
Thanks! I'll take a look at it. At the source code too. No better learning school than live code :)
It's an OO world.
-
The most productive feature of XAML: COPY PASTE EDIT. I've found that ANYTHING I want to do in XAML is documented on a blog somewhere, COPY PASTE EDIT. You can't COPY PASTE EDIT a screenshot of a WinForm. Also, don't be afraid to use the designer to drag and drop buttons, labels, textboxes, etc. from the Toolbox. Visual Studio will autogenerate working XAML for you, and usually the only XAML you need to add by hand is the databindings. Then COPY PASTE EDIT this autogenerated XAML to create the rest of your controls.
Justin Kalweit wrote:
Also, don't be afraid to use the designer to drag and drop buttons, labels, textboxes, etc. from the Toolbox.
I've heard the opposite sound too. I tried it at first, but it seemed weird... XAML sets the Height and Width Properties if you use this method, which means your possibilities for automatic scaling are none. So even when you drag/drop from the Toolbox you'd need to edit the XAML file. I really find it unbelievable that Microsoft auto-generates those Properties while a major part of WPF is to not use them so everything auto-scales :confused:
It's an OO world.
-
Thanks! I'll take a look at it. At the source code too. No better learning school than live code :)
It's an OO world.
No prob! It's actually pretty simple, so should make a good example. If you have any questions about how anything works I'm happy to answer them!
Sad but true: 4/3 of Americans have difficulty with simple fractions. There are 10 types of people in this world: those who understand binary and those who don't. {o,o}.oO( Check out my blog! ) |)””’) http://pihole.org/ -”-”-
-
Yeah, I have some tips. * Make something like Charles Petzold[^]'s XAML Cruncher. Well, try it, and then make your own. * Make a bunch of simple things with it before you bite off more than you can chew. It's really disappointing when you have this great idea for a GUI and then you drown in the XAML implementation because you didn't work through enough of the required ideas. * Read Sacha Barber's WPF articles[^] (scroll down to them.) His WPF code really sets a good standard. * Get yourself a copy of Expression Blend, if you can afford it. If you can't, at least get the express edition of Visual Studio for Windows Phone development, that has it. Then you can really play with these things in a GUI that was truly made for XAML development, and see how it all works. * Don't let this one scare you: It feels like a lower level than WinForms in some ways. You don't have to think about it often, but when you want to change the way it looks or feels, you'll get a good look at the guts. It has more guts than WinForms or MFC or anything else in @favorite_framework. Seriously. You'll have to think in terms of "What are the basic elements that compose this UI element" sometimes. Things as simple as a Button are made of borders and decorators and content presenters. A ScrollBar is broken down into its components. And just fuhgeddaboutit when you want to style a DataGrid until you've successfully styled less complex controls. Finally, don't listen to everything everyone tells you about it. Go, make things with it, and see for yourself how well it works for you.
djdanlib wrote:
* Read Sacha Barber's WPF articles[^] (scroll down to them.) His WPF code really sets a good standard.
Reading Sacha's articles is always a great tip :thumbsup:
djdanlib wrote:
Don't let this one scare you: It feels like a lower level than WinForms in some ways.
Well, that's the fun part isn't it? :laugh: Thanks for the great tips!
It's an OO world.
-
Justin Kalweit wrote:
Also, don't be afraid to use the designer to drag and drop buttons, labels, textboxes, etc. from the Toolbox.
I've heard the opposite sound too. I tried it at first, but it seemed weird... XAML sets the Height and Width Properties if you use this method, which means your possibilities for automatic scaling are none. So even when you drag/drop from the Toolbox you'd need to edit the XAML file. I really find it unbelievable that Microsoft auto-generates those Properties while a major part of WPF is to not use them so everything auto-scales :confused:
It's an OO world.
Yeah, most of the UI in my apps are basically data entry forms or displays, and most of the fields are short, 25-50 chars. They actually work better when the size is set explicitly, for example if the user maximizes a window, it usually doesn't make since for a text box to span the entire screen. Occasionally I need a control to scale, so I simply remove the Width property manually. But in general, I use the designer to set my sizes and positions.
-
Yeah, most of the UI in my apps are basically data entry forms or displays, and most of the fields are short, 25-50 chars. They actually work better when the size is set explicitly, for example if the user maximizes a window, it usually doesn't make since for a text box to span the entire screen. Occasionally I need a control to scale, so I simply remove the Width property manually. But in general, I use the designer to set my sizes and positions.
That's cool. To each his own and I see your point. But I was thinking on forgetting Height and Width Properties and use their Minimum and Maximum variants. But using the designer just doesn't work that way. I'd have to set those manually anyhow. Although perhaps having some XAML generated and then editing that isn't such a bad idea :)
It's an OO world.
-
Alex Fr wrote:
- Learn to love XAML. It's weird
and awkward at first, but once you get used to it, it's magic.
I tried to get into WPF a couple of times and each time I was driven mad by the XAML bit. Coming from C++ and MFC, WinForms and C# seemed like a blessing when it came to making nice, functional interfaces. All (or at least most) of the properties for the components are in a nice properties box that you can modify to your hearts content. I don't really get why WPF seems to have gone backwards in usability by only having some properties exposed and everything else in the XAML, where you have to not only remember the name of the thing but also all of the properties. Don't get me wrong, I'm not trying to start an argument, I really just want someone to explain to me from a programming point of view, what makes WPF better than WinForms? Thanks Dave
From a programming point of view, it is more painful (and more challenging). From a user point of view, it looks cooler, even with the useless animations.
- Learn to love XAML. It's weird
-
Alex Fr wrote:
- Learn to love XAML. It's weird
and awkward at first, but once you get used to it, it's magic.
I tried to get into WPF a couple of times and each time I was driven mad by the XAML bit. Coming from C++ and MFC, WinForms and C# seemed like a blessing when it came to making nice, functional interfaces. All (or at least most) of the properties for the components are in a nice properties box that you can modify to your hearts content. I don't really get why WPF seems to have gone backwards in usability by only having some properties exposed and everything else in the XAML, where you have to not only remember the name of the thing but also all of the properties. Don't get me wrong, I'm not trying to start an argument, I really just want someone to explain to me from a programming point of view, what makes WPF better than WinForms? Thanks Dave
"what makes WPF better than WinForms" Flexibility. The ability to make any control look like you want it to look with only a few lines of xaml. Easy animation. I also love the decoupling of the actual GUI and the "gui logic". Through the mvvm pattern, I literally never (with a few exotic exceptions) have to deal with controls directly. All I deal with is controllers, business calls and presentation models. I feel like it simply results in a much better structured and layered application. The XAML specifies how it looks on screen, based on the state of a presentationmodel. In code, all I need to do is maintain the state of that model and everything on screen will automagically adjust to changes. And if the user makes changes in the GUI, the model likewise automagically gets updated and from there you do whatever you want. What's not to like? I fell in love with it from day one.
- Learn to love XAML. It's weird
-
Started reading this huge book[^] (yes, VB and I'm proud of it! So don't start...) ;) Learning the "zammel" stuff, forgetting all I know about Events and Properties and thinking some very advanced controls are standard WPF stuff then finding out I have some DevExpress stuff installed... :doh: I've been planning this for months, and I finally started! Any tips for a WinForms going WPF programmer? (and no, I don't find this a programming question) :)
It's an OO world.
Make your life easy, learn all you can about Dependency Properties. Everything else is cake from there. Binding, Controls, UI... It's all Based on the abilities of the Dispatcher. Learn that and everything will be easy(er).
-
Make your life easy, learn all you can about Dependency Properties. Everything else is cake from there. Binding, Controls, UI... It's all Based on the abilities of the Dispatcher. Learn that and everything will be easy(er).
Thanks for the tip. Haven't looked into it yet, but certainly will do so soon :)
It's an OO world.
