Finally started doing some WPF...
-
Ian Shlasko wrote:
The code-behind is the glue that links the GUI to the model... Ideally, that's ALL it does... Realistically, the lines tend to blur a little with more complex applications.
Espeacially when using things like infragistics[^]. [EDIT] Correct spelling of Infragistics... I wonder if that is what got me the 1 :((
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
modified on Tuesday, August 30, 2011 10:14 AM
I spell it Infrashitstix. I've used their stuff, and we scrapped it and moved to the Silverlight toolkit instead.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"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 -
It can't be THAT bad... Right? :confused: Well, I'm still young and flexible so perhaps I can just sort of roll into it... Maybe ;p
It's an OO world.
Naerling wrote:
It can't be THAT bad... Right?
Yes, it's that bad.
Naerling wrote:
Well, I'm still young and flexible
All that means is that you'll be able to more easily bend over backwards to make your app work the way you want it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"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 -
If you have any ASP.NET in your background, this[^] might help a little bit to get you in the right mindset.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Nope - won't help at all, with the possible exception of forming a closer bond with pointy brackets.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"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 -
Naerling wrote:
It can't be THAT bad... Right?
Yes, it's that bad.
Naerling wrote:
Well, I'm still young and flexible
All that means is that you'll be able to more easily bend over backwards to make your app work the way you want it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"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, 1997John Simmons / outlaw programmer wrote:
Yes, it's that bad.
Recommendation to stay with WinForms? :~
John Simmons / outlaw programmer wrote:
All that means is that you'll be able to more easily bend over backwards
I'm a programmer... I sit on my ass all day. The moment I try to bend (whichever direction) my back, shoulders and neck start to hurt and I know I just should've stayed in my chair ;p
John Simmons / outlaw programmer wrote:
to make your app work the way you want it.
If I can make it work at all (especially in WPF) ;)
It's an OO world.
-
John Simmons / outlaw programmer wrote:
Yes, it's that bad.
Recommendation to stay with WinForms? :~
John Simmons / outlaw programmer wrote:
All that means is that you'll be able to more easily bend over backwards
I'm a programmer... I sit on my ass all day. The moment I try to bend (whichever direction) my back, shoulders and neck start to hurt and I know I just should've stayed in my chair ;p
John Simmons / outlaw programmer wrote:
to make your app work the way you want it.
If I can make it work at all (especially in WPF) ;)
It's an OO world.
Both Winforms and WPF suck in their own little ways. It really depends on where you like your suckage. By all means, give WPF a try (check out my Reputationator article series if you want to see the same app written for both platforms in a single download).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"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 -
Both Winforms and WPF suck in their own little ways. It really depends on where you like your suckage. By all means, give WPF a try (check out my Reputationator article series if you want to see the same app written for both platforms in a single download).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"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, 1997I'll check them out! Quite a read though... :thumbsup:
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!
Alex Fr wrote:
2. Learn not to hate XAML.
I'm just not sure that will ever happen. The hate may have become a little less searing, but it's still there.
Alex Fr wrote:
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!
I once worked in a place that took this idea to the extreme whenever they could. Impossible to describe so much failure, should have sent a poet. :wtf:
-
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.
Naerling wrote:
Any tips for a WinForms going WPF programmer?
First off, forget about the "Forget everything you know..." ideas out there. It's different, but it's still programming. In the end, you will still spend a lot of your time worrying about program flow, threading, inheritance, assembly references, and all sorts of other things you had to deal with in WinForms. To me it seems like WPF differs from WinForms mainly in two ways: 1) The GUI components is different. 2) The way your "working" code (the code that actually does stuff) interacts with the GUI is different. Now, to elaborate on the above two points: 1) This is, of course, the "zammel stuff" as you call it. As in WinForms, the IDE allows you to design the GUI completely through drag-and-drop, and generates the corresponding code for you. But unlike WinForms, WPF generates code in the form of XAML files. These are nothing more than specialized XML files, so it's not hard to read and understand the syntax. This also lessens the "don't touch the auto generated code because you will break it and your changes will be overwritten when it is re-generated" attitude. It's easy to look at and edit the XAML directly, so you don't have to rely on the GUI builder for every small change you want to make. 2) By now I'm sure that someone would have told you about data binding :) . This is the big selling point of WPF, and the biggest thing that you will have to get used to. If you go the WPF route, you will find yourself pretty much abandoning event handlers in favour of binding. This is because ANY property on a visual control can be bound to a property in you code. You can have a bool to specify if a control should be enabled or not. You can bind a label or textbox's text to a string, or even both to the same string if you wish. You can... you know what, just read your book; you'll find out that there are tonnes of fancy stuff you can do with data binding that will make your life easier. Keep in mind that the biggest advantage of data binding is to separate presentation from logic. This will help you fight the urge to revert to WinForm habits, such as accessing a control's properties through an object of the control. In essence, all properties that you might want to change should be bound, and then you change your properties instead of those of the control. If possible, try to position yourself so that designers create the XAML files and then hands it over to you
-
Naerling wrote:
Any tips for a WinForms going WPF programmer?
First off, forget about the "Forget everything you know..." ideas out there. It's different, but it's still programming. In the end, you will still spend a lot of your time worrying about program flow, threading, inheritance, assembly references, and all sorts of other things you had to deal with in WinForms. To me it seems like WPF differs from WinForms mainly in two ways: 1) The GUI components is different. 2) The way your "working" code (the code that actually does stuff) interacts with the GUI is different. Now, to elaborate on the above two points: 1) This is, of course, the "zammel stuff" as you call it. As in WinForms, the IDE allows you to design the GUI completely through drag-and-drop, and generates the corresponding code for you. But unlike WinForms, WPF generates code in the form of XAML files. These are nothing more than specialized XML files, so it's not hard to read and understand the syntax. This also lessens the "don't touch the auto generated code because you will break it and your changes will be overwritten when it is re-generated" attitude. It's easy to look at and edit the XAML directly, so you don't have to rely on the GUI builder for every small change you want to make. 2) By now I'm sure that someone would have told you about data binding :) . This is the big selling point of WPF, and the biggest thing that you will have to get used to. If you go the WPF route, you will find yourself pretty much abandoning event handlers in favour of binding. This is because ANY property on a visual control can be bound to a property in you code. You can have a bool to specify if a control should be enabled or not. You can bind a label or textbox's text to a string, or even both to the same string if you wish. You can... you know what, just read your book; you'll find out that there are tonnes of fancy stuff you can do with data binding that will make your life easier. Keep in mind that the biggest advantage of data binding is to separate presentation from logic. This will help you fight the urge to revert to WinForm habits, such as accessing a control's properties through an object of the control. In essence, all properties that you might want to change should be bound, and then you change your properties instead of those of the control. If possible, try to position yourself so that designers create the XAML files and then hands it over to you
Chapter 19, page 591, of my book is about data binding... I only have 400 more pages to go before I can actually get to what's here considered to be one of the most important features of WPF... X| Not, or rarely using Event Handlers is interesting... I might just skip 400 pages and get right to the good stuff ;p
Member 7967850 wrote:
If possible, try to position yourself so that designers create the XAML files
Not possible. I am learning this on my own. At work I still have to use WinForms (for the time being). I was thinking of first doing all the XAML, creating Grids, configuring them, do some neat colouring, making a TextBox within A Grid within a TextBox within a CheckBox or whatever (yes, I was quite surprised that that is possible ;p ) and then getting to doing some Events and DataBinding. Small chuncks at a time is certainly the best way to go though :)
Member 7967850 wrote:
OK, I think I've said enough for now. Good luck and have fun.
Thanks, I will! :D Quite a nice and detailed answer for a third post by the way :)
It's an OO world.
-
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.
Tip: use C#
-
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.
Naerling wrote:
Any tips for a WinForms going WPF programmer?
Learn to count to 10. There will be times that you'll simply want to throw your monitor out the window when simple stuff that were so easy to accomplish on WinForms becomes a daunting task on WPF. You may start to wonder if the pretty print is worth it.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
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.
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/ -”-”-
-
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.
