Finally started doing some WPF...
-
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.
-
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?
- 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) -
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? (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
-
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?
- 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:
- 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!
-
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!
Clearly, you don't like WPF :)
Alex Fr wrote:
1. Forget that you are programmer. Now you are computer graphics maker/script writer.
When you're writing an application with a GUI, you need to be both a programmer AND a designer (Obviously, in larger teams, these tasks would be split between specialists)... When you're in the XAML, think like a graphic artist... When you're in the code-behind and working on your data model and business logic, think like a programmer.
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!
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.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
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, but once you get used to it, it's magic.
Its funny how many people I have seen jump in and then go "ahhh wait a minute", right when they hit the XAML. Heck I did it myself, but as you put it you get use to it and start to appreciate it.
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.
-
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.
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
-
Clearly, you don't like WPF :)
Alex Fr wrote:
1. Forget that you are programmer. Now you are computer graphics maker/script writer.
When you're writing an application with a GUI, you need to be both a programmer AND a designer (Obviously, in larger teams, these tasks would be split between specialists)... When you're in the XAML, think like a graphic artist... When you're in the code-behind and working on your data model and business logic, think like a programmer.
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!
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.
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:
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
-
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.
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
-
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
Man, don't get me started... X|
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
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.
-
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.
Databinding, databinding, databinding. Databind everything. Databind your controls. Databind your labels. Databind your error messages. Databind your buttons. If you set a property on a control without databinding (or XAML), then that's a smell that you might be doing it wrong.
-
Databinding, databinding, databinding. Databind everything. Databind your controls. Databind your labels. Databind your error messages. Databind your buttons. If you set a property on a control without databinding (or XAML), then that's a smell that you might be doing it wrong.
Thanks. I'll keep that in mind! :)
It's an OO world.
-
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
ASP.NET (or web development in general) is the other thing I should start with sometime... :^)
It's an OO world.
-
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
-
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
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:
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
Abhinav S wrote:
- Do not, I repeat do not, go for the event programming model of Windows Form.
I got that from the book... The Events model is quite a drag to master it seems :doh: Especially as VB programmer I am used to the Handles keyword at the end of a Method... Luckily I've done some C# too, to get a feeling with some non-VB approaches :)
Abhinav S wrote:
- Always try and think about 'binding' properties.
I will!
It's an OO world.
-
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
-
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!