Finally started doing some WPF...
-
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.
