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
-
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)Ian Shlasko wrote:
Learn to love XAML. It's weird and awkward at first
That's an understatement! ;p But I'm managing :)
Ian Shlasko wrote:
In a perfect world, your code-behind should NEVER* have to refer to a GUI control.
I like knowing what it would be like in a perfect world. If I know how and try to write perfect code at least I don't end up with completely horrible code ;p Thanks for the tips!
It's an OO world.
-
Thanks. I'll keep that in mind! :)
It's an OO world.
Just remember Binding(in case you forgot) :laugh:
Live for today. Plan for tomorrow. Party tonight!
-
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.
Good luck! I'm just converting a relatively big project from Winforms (it used to be excel 10 years ago...) XAML is great. Documentation is poor on official MSDN. I also use XBAP to make it Web easy. WCF (for data service) is also great. You will use a lot of dispatching, have a lot of crashes... Have fun!
-
Collin Jasnoch wrote:
infagistics[^].
I love your (subtlety ? lapsus ?) contraction:
infamous U infragistics = infagistics. -
Yeah typos suck.. but should they result in a 1 vote??
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.
Maybe an infragistics dev did it.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
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!
Amen brother... I just posted an update to an article series of mine with a WPF app that creates charts. The entire chart is created in code instead of XAML (with the exception of a few control templates for tooltips). I hate XAML (which is probably going to make my WPF/Silverlight experience less than fulfilling).
".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 -
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.)
