Windows Forms is pretty old now, and has been superseded by WPF. I've seen a lot of material regarding databinding WPF layouts, using the MVVM pattern for the applications and some cool animations to boot.
I think it's time for me to abandon the Winforms ship and start using WPF. Once I finish this last freelance project I'll start using WPF exclusively for my Windows Clients.
I have the privilege of having customers with newer machines, so running WPF on their machine won't be a problem. :)
Trying to grab the entirety of WPF is extremely daunting and I feel that if I just dive right in I might keep doing things the Winforms way when in fact WPF has a newer, more succinct way of doing things.
Where do you recommend I start? What are some things you wish you knew before using WPF for production? What book would you recommend that teaches you about WPF (has to be new! nothing from 2007)?
I've just done the exact same thing. I am in the process of moving some apps to WPF. I've decided not to bite off MVVM just yet, or any VM. I'm just trying to learn the basics of WPF. I have found SO, other internet sites and this book very helpful.
BTW, I'm finding it's much easier than I thought. Takes some getting used to, but I'm already hooked (XAML is very cool). I'm convinced the best to learn is to simply jump in and start doing it.
The main advice I can give is to "forget" what you have learned with winforms. Do not try to apply what you did with winforms to wpf... The architecture is quite different and you risk to fall into traps.
Maybe MVVM is not required at your early stages of learning, but its approach make the WPF coding easier than without. Take a look not so late at the MVVM Light Toolkit. This MVVM framework is really light but provide what is required for a full MVVM framework, and only that.
good luck, and do not hesitate to take a look at Silverlight also. The border between the desktop apps and web apps are as slim as ever.
How I'd start teaching someone WPF today:
Make sure they have a solid grounding in XML. If you don't know how to edit XML documents and diagnose and fix problems in markup, you're not going to be able to make progress with WPF. You especially need to be able to work with XML namespaces and understand namespace prefixes without freaking out.
Create an example application that creates a bunch of text boxes and binds them to the properties of an object that implements change notification. Data binding is the fundamental technology of WPF, as far as I'm concerned. Once you understand binding - and it's not that hard to understand, really - the design of things like dependency properties and styles become a lot easier to grasp.
Add additional object types to the application and demonstrate how data templates and template selection work.
Add styles, particularly styles that use data triggers, to the example application.
Add items controls to the example application and demonstrate how items panels and item container styles work. Maybe take a little journey into the different kinds of panels. Walk through how observable collections and INotifyCollectionChanged work. At this point I might possibly create a piece of the example collection that used an ItemsControl with a Grid as its items panel, so that I could walk through item container generation and attached properties.
Refactor the example application to move styles and data templates into resource dictionaries, to demonstrate how resource dictionaries work.
Walk through the design of dependency properties, tying their design back to the concepts we've already mastered. To show this off, I like to add a modal dialog that contains a font-selection combo box for the entire application.
Add commands (using the RelayCommand pattern) to the back-end objects, to demonstrate how commanding works.
Refactor the example application to use user controls.
Walk through customizing a control template.
I don't know of any WPF tutorial that approaches the problem like this, unfortunately.
What i think is most important:
Databinding, one of the most outstanding features of WPF, takes a while to get used to though.
Commands, not sure if there is something like this in WinForms...
DataTemplates, create large parts of the UI on the fly based on data.
Styling, if you need customized controls.
Also you should probably acquire basic XML knowledge if you don't have that already to be able to write XAML (I wouldn't use the designer in VS).
I would heartily recommend the book WPF Unleashed by Adam Nathan. It's how I learned WPF, and I still reference it regularly now, years later. Great introduction that explains things in a clear order, gradually building up skills.
I echo what was said above - forget much of what you know in WinForms. If you try to think of WPF as a "prettier WinForms" you'll not get the full benefit of the platform. Learning to "let go" a bit and embrace Data Binding (SO much better in WPF), and to embrace the idea that controls don't have speficic visuals, then you will be truly free to use WPF to its fullest.
'WPF in Action' is a great book to read before starting any coding. Its very simple to understand and if you have the patience you can go through the entire book in a day or two. It doesnt have any MVVM stuff so for someone coming from a winforms background its great to start with.
Once you 'get the hang' of WPF concepts you can jump into MVVM. Two great MVVM resources I found when learning all things WPF were
1. Video by Jason dolinger
2. MSDN article by Josh Smith
Related
I'm starting learning about WPF technology and I have found that the UI of WPF is fixable and better than window form but it takes long time to master it. For example, using command, using data binding, and using MVVM pattern and more. My purpose is that I want to use WPF interface and coding style is the same what I did in window form. So, is it the good idea for starter? and is it difficult to maintenance project or not?
let me try to explain WPF a bit futher. The primary purpose of WPF was to enable a flexible UI with hardware acceleration so that a developer like us is not limited by the capability of the platform to show their creativity. WPF gives you the power of XAML with strong binding capabilities and with the use of MVVM you can take it to never before levels.
So if you stik to the Win Forms coding practices and standards which are usually hardwired event driven programming, you may find it difficult to find out what WPF bring for you and would be difficult to leverage the true beauty of programming in WPF.
I am a WPF developer, when I started I did exactly the same way and invested much of time doing WPF if old way. I made my decision that WPF is nothing new it is simply a new framework with some enhanced features.
Sooner I begin to see some nice samples on wpf communities and they were awesome piece of work. Then I realized that I am going in a different direction then WPF one.
So I would personally not like you to invest your time in a old way rather you can pick up in WPF kind of style. Work directly on XAML, do bindings for properties and events. Use styles and templates to give the desired look. And far important try to achieve declaratively instead of programatically.
I hope this may help you. Should you need more explanation do not hesitate to ask.
For wpf projects MVVM is the most suitable and maintenance wise it is more convenient. In case of learning purpose and for the small projects we can go ahead with code behind.
I have a little program which I made with WinForms and now I want to make it again using WPF.
I'm new to WPF and I read that whatever you can do with XAML, you can also do without it, meaning using code only.
Of course that you don't have any XAML when using Winforms. Can I use the same code for the WPF application that I used for the winforms application and get the same result? Or do I need to create and edit XAML? What are the advantages of using or not using XAML?
Also, considering the past experience using Winforms, should I somehow change the way I'm thinking about design and implementation that worked for Winforms but are not that appropriate for WPF?
No you can't reuse code from winforms in WPF.
and even if you could, you shouldn't.
whatever you can do with XAML, you can also do without it
You should really use XAML to define the UI, and then use DataBinding and MVVM, which is a much more professional way of development than the traditional procedural winforms approach.
Not using XAML is much more troublesome than using it. It may look intimidating at first but it's a really awesome thing to work with.
Of course that you don't have any XAML when using Winforms
No, of course not. winforms is a really old technology that doesn't support anything. That's why they created the Visual Studio designer, otherwise no one would have ever used winforms for anything, because of the horrendous gargantuan behemoth amount of code required to do anything useful.
Can I use the same code for the WPF application that I used for the
winforms application and get the same result?
Probably, by adapting some class names and whatnot, but then you lose the main advantage provided by WPF, which is precisely getting rid of the horrible winforms-like code.
considering the past experience using Winforms, should I somehow
change the way I'm thinking about design and implementation that
worked for Winforms but are not that appropriate for WPF?
Yes. WPF supports MVVM, and that requires a really different mentality from the traditional winforms approach.
I strongly recommend reading Rachel's Excellent Post about upgrading from winforms to WPF.
I tried converting a Winforms app to WPF directly, and it causes way more issues than you need because you are fighting the framework all the time. Read up on MVVM and databinding and use that. Its what WPF is designed around, and comes with several advantages such as testability. You can actually get quite a long way with a few of the simple concepts (databinding, viewmodels etc...) and expand your knowledge as you go, but I'd recommend an understanding of MVVM and databinding in WPF first.
A good framework to get started with would be MVVMLight, but its worth writing the basics without a framework to get to know how things work first.
I seem to remember this being a good set of posts from reed copsey: http://reedcopsey.com/series/windows-forms-to-mvvm/
Trying to create WPF controls without XAML is asking for trouble - the whole framework is built around the MVVM pattern which demands that your View be described in a declarative fashion, rather than a procedural fashion. While you can definitely create same UI objects in C# and XAML, doing so in C# will require you to know (in truly excruciating detail) how the framework operates in order to compensate when the state of your UI changes. On the flip side, if you do it XAML (as WPF dictates you are supposed to), then things generally update just fine and without the necessity of working around endless bugs. In short "yes" you can do it in code, but "no" you can't do it in code without losing your sanity.
Actually it depends on how complex is your project. For quite a small project you can make this "conversion" quite simply. But it's not a good practice even because WPF development often is based on MVVM/Prism and they give you lots of advantages.
Also the behavior of your UI might be different - it depends on the complexity of your project.
I'll 2nd or 3rd or 4th the other answers. Never, ever, ever, ever, ever try to build a WPF app with "Winforms style" code. I did that on my first ever WPF app and it was the biggest mistake I've ever made. What a gigantic mess. The 2nd app I went half-way towards MVVM and that too was a gigantic mess. 3rd app and ever since I've gone 100% MVVM, DI, etc. and 100% by the book WPF and code is super clean.
There isn't really a point in porting Winforms code to WPF any way. The majority of the code you wrote in Winforms is thrown out when you go WPF. Basically the only portable stuff is the business logic. All the UI logic is completely different.
And you'll thank us later because one of the greatest concepts ever about WPF is the separation of UI and business logic. That makes swapping out controls a piece of cake.
Keeping in mind what CannibalSmith once said - "All the answers are saying "WPF is different". That's a huge understatement. You not only have to learn lots of new stuff - you must forget everything you've learned from Forms. It's a completely new way of doing UI."
.. and having many years of experience with visual Windows desktop applications development (VB6, Borland C++ Builder VCL, WinForms) (which is hard to forget), how do I quickly move to developing to say well-formed WPF applications with Visual Studio?
I don't need boozy-woozy graphics to give my app look and feel of a Hollywood blockbuster or a million dollar pyjamas. I always loved tidiness of standard Windows common controls and UI design guidelines, end even more I enjoyed them under Vista Glass Aero Graphite sauce.
I am perfectly satisfied with WinForms but I want to my applications to be built of the most efficient and up-to-date standard technologies and architectured according to the most efficient and flexible patterns of today and tomorrow, leveraging interface-based integration and functionality reuse and to take all advantages of modern hardware and APIs to maximize performance, usability, reliability, maintainability, extensibility, etc.
I very much like the idea of separating view, logic and data, letting a view to take all advantages of the platform (may it run as a web browser applet on a thin client or as a desktop application on a PC with a latest GPU), letting logic be reused, parallelized and seamlessly evolve, storing data in a well structured format in a right place.
But... while moving from VB6 to Borland C++ Builder was very easy (no books/tutorials needed to turn it on and start working) (assuming I already knew C++), moving from BCB to WinForms was the same seamless, it does not seem any obvious to me how to do with WPF.
So how do I best convert myself from a WinForms developer into a right-way thinking and doing WPF developer?
Read this questions:
How to begin WPF development?
Is there a WPF Cheat Sheet outhere?
Learning MVVM for WPF
Learning WPF and MVVM - best approach for learning from scratch
MVVM: Tutorial from start to finish?
Download and work through this Microsoft tutorial: Southridge Hands-on-Lab
Check this videos:
Mike Taulty's series of videos
Jason Dolinger on Model-View-ViewModel
And after that, take a look at StackOverflow questions tagged with both wpf and mvvm
Keep in mind that MVVM seems suited only to single window applications.
I dived into WPF based on inexperience and general recommendations that it would suite better a kiosk project, especially one where the customer has given me photoshop images of all the application screens. Having cool graphics was a requirement for this project and I liked the vague resemblance of WPF with web development.
I found out a few downsides
1) there is no such thing as an official MVVM toolkit. There are a lot of them, all backed by an individual. A shot at a toolkit by Microsoft has been put on the back burner one year ago and there is no VS2010 support.
2) programming a multi windows application, sort of a simple wizard with back and forward, is plain nightmare. I got out of this with a clean design defining a delegate for each UI action and a command for each business action, but still I think it is too much involvement with a framework to be justified, and you cannot show the result of your tests to this customer expecting excitement.
3) You give up the habit of double clicking a button and adding some code. This leaves a nagging feeling of using the IDE against its nature. Basically you use Visual Studio as a text editor and an interface designer, still with a great help from the tool.
The upsides, so far are:
1) defining visual components is very flexible, fast and easy and you can choose between VS and Expression Blend. Animations are simple to create.
2) data binding simplifies the application. You define a DataContext and bindings and do not have to move data from the business logic to the interface yourself, as long as you have a property for everything that must be displayed.
3) You can reduce the amount of business logic in the interface to zero. It is easy to separate the application behaviour from its looks, so you can skin your interface in ten different ways with little effort and test all of your logic without opening a window.
4) you leave a door open to going with Silverlight if they ask you.
My conclusion is that if you have an MDI application in mind you might find yourself in big trouble. You should be aware that, if you choose WPF, you are ploughing ground for future generations rather than getting on a train that will get you there fast and easy. There is no established way to do things, especially those that are not covered by demos.
Toolkits, all things considered, are not so important and each of them will serve you well. In fact a couple supporting classes are enough to start and there are no fancy wizards, it is up to you to follow conventions.
You might even make your own if a few hours, once you understand what is involved in the logic. The downside is that you will have to really understand it well to bend the application your own way.
As I said above, I had to learn a lot just to show a new view when they click a button keeping the code clean. Take the time to see the videos cited elsewere on StackOverflow it will save you time.
if you are looking for books just look at this previous post
What WPF books would you recommend?
Having got into WPF this year, the most important thing for me was learning how to use the Model View View-Model pattern for separating the view from the app logic. As a general rule of thumb if you find you are placing a lot of code in the code behind for your view then you are "doing it wrong".
I found that coming from a WinForms background I was putting in lots of event handlers and doing stuff in my code behind. As I became familiar with MVVM and WPF features I found I was able to remove the bulk of my code behind and replace it with views binding to view-models.
It was articles like this one from Josh Smith that helped get me started on the MVVM path:
http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx
Once you have started to get the hang of displaying data view MVVM bindings, have a look at commands and specifically the ICommand interface. They are the main mechanism by which actions from the user triggers operations to execute. So rather than having a OnClick handler for buttons, you bind the Command property of the button in XAML to a property in your view-model that exposes an ICommand implementation.
My 2c - Donovan
Try this smashing hit.
Windows Presentation Foundation - Unleashed By Adam Nathan
(source: adamnathan.net)
I've seen a lot of questions about the merits of WPF here, and essentially every answer says it's the bee's knees, but essentially every answer also talks about things like XAML, in many cases graphic designers and Expression Blend etc. My question is, is it worth getting into WPF if you're a solo coder working in C# only?
Specifically, I don't have a graphic designer, nor any great talent in that area myself; I don't use point-and-click tools; I write everything in C#, not XML.
Winforms works fine in those conditions. Is the same true of WPF, or does it turn out that important functions can only be done in XAML, the default settings aren't intended for actual use and you have to have a graphic designer on the team to make things look good, etc., and somebody in my position would be better off to stick to Winforms?
I'm a code person myself, and to be honest, it doesn't matter. Even if you don't know anything about graphic design, you can still use the editor in visual studio to design an UI. The designer features an drag&drop designer as Win Forms does, so that doesn't really pose a problem. Even though I'm a code person, I have no problem with xaml, as it is, in some way, code again. I had problems with the xaml at first as well, but I got used to it, and stuff I had to do in code in Win Forms was quite easy in xaml.
Databinding simply rocks, you don't have to care about getting the data to the UI, you simply have an ObservableCollection<T> or similar, and one Property in the xaml code and everything gets done for you. Want to format the data? Simply add a formatting property to the binding. Want to color the text according to the value? Template Selector class with 15 lines of code, Binding and Template selection in the xaml code of about 10 lines. I'm really growing to love it, and with time (as with any other new technology) you get used to it, and produce good looking stuff.
Short answer: is yes, you can do WPF with code only.
Longer answer: The part about a designer being able to work on the UI and a developer on functionality is really just a side-effect of decoupling functionality from presentation.
What WPF brings to the table in a powerful way is data-binding which enables you to use wider range of design patterns. MVVM has been discussed quite a bit recently.
The various MVVM framework encourage convention over configuration allowing you to write less code to accomplish the same goals.
This decoupling also has the nice side effect of making your application more testable (you don't have to write tests if you don't want to, but at least the option is there).
Moving to WPF from WinForms will most likely be worth it for you for new development. You could in theory keep doing what you've been doing with WinForms (just with new libraries), but it gives you the option to incorporate newer tools into your development as you become more comfortable with technology.
If you haven't seen it already, the BabySmash series by Scott Hanselman is pretty interesting.
IMHO, it is worth going the WPF route if only to ensure that you build these skills. I have toyed with Silverlight which is XAML based and I could transfer much of that knowledge to WPF even though SL is a subset.
And to be honest once you get used to it, most UIs are build just as easily with WPF as with WinForms. And the tooling is quite nice, using SketchFlow for prototyping is useful, and does not require you to have any real artistic skills other than what you have for doing WinForms stuff. I believe going forward, it would only benefit me to be learning more about WPF, and I believe that would be the case for others.
Everything that can be done in XAML can also be done in code due to the fact that XAML is merely a DSL for instantiating and configuring graphs of objects - specifically those in the WPF library (System.Windows). If you're building line of business apps, then there's very little that WPF offers that isn't available at all in WinForms. The key difference is that WPF allows you to do many things much more easily and flexibly, due to its more advanced object model.
I think that WPF is certainly worth learning, but if you want to do it without learning XAML, then I think you'll probably find it more difficult grok.
It's also worth considering that many WPF developers write the XAML by hand (whereas their designer counterparts will be more likely to use Blend in the first instance) partly through necessity (the WPF designer prior to Visual Studio 2010 wasn't very good) and partly because the object model lends itself to a more concise expression in XAML than in C#. XAML is itself quite a small language but the object model it is used to define (the WPF object model) is huge - and that's where the complexity comes from.
If you have no compelling reason to stop using WinForms, then don't. However, if you can push aside your preconceptions about writing code in XML rather than C#, then I think you might be surprised how this different approach to building a UI might clean up your code.
I say WPF can be for you, and if you don't want to go the xaml way and do code only you should go ahead and do that, in xaml certain thing are impossible but it is the preferred way of doing layout, but no one forces you not to do it in code, however if you learn xaml you will produce UI elements faster, then you would in code, so that's something to remember.
this is an old post but...
To my opinion, there are no bounderies when you code by your self in any environment and that always something needs to be discovered. People have created layouts in code for many years in the past, but certain factors moved the community to create graphic and ui tools. But again, nothing lasts for ever and trends change quickly. Also remember the transition from ASP inline coding to layout composition style of ASP.NET and then back to inline with ASP.NET MVC. Was it a step back? Certainly not, because it was supported with other techniques and tools like razor, dynamic language, model binders and more.
So, actually noone can tell you the right way to work as long as you follow basic rules and standards and realise that it's not just code but rather today's code, with all the lambdas, linqs, expressions, anonymous, DLRs etc.
Who knows? Maybe you will be the one to create a new way of expressing and driving content.
We're in the early design/prep phases of transferring/updating a rather large "legacy" 3 tier client-server app to a new version. We’re looking at doing WPF over Winforms as it appears to be the direction Microsoft is pushing development of the future and we’d like the maximize the life cycle/span of the apps. That said during the rewrite we’d like to make as many changes to our data access/presentation model to improve performance as much as possible up front as many.
I’ve been doing some research along that vein but the vast majority of the resources I've found that discuss WPF focus only simple data tracking apps or focus on the very basics UI design/controls. The few items that even discuss data presentation are fairly elementary in depth.
Are there any books/articles/recommended reading/other resources recommended for development related to large enterprise level business apps?
Any “gotchas” that should/could be avoided?
General advice to minimize the time underwater
I've been developing a large enterprise-wide WPF application for almost 2 years. As with any UI development, it's important to understand the best UI design pattern for the particular technology you are using. From my experience with WPF, the Model-View-ViewModel design pattern is the most prevalent. Once you understand the data binding powers of WPF, it is easy to see why a pattern like the M-V-VM is so accepted. Even if you don't follow the M-V-VM pattern (or a variation of it) word for word, understand the big picture solution that the pattern addresses. Basically, keep your UI/XAML file (View) in a separate file and all the code-behind/logic (ViewModel) in another file. The View simply reacts to changes in the ViewModel.
Keeping the ViewModel separate, you'll have several benefits.
Easy to create automated tests for the ViewModel object because there are no graphic components in it. It's just an object with methods/properties.
Easier to split the work up between developers (e.g. one developer builds the View while another developer is building the ViewModel).
It's much easier to use multi-threading in the ViewModel since it never interacts directly with UI controls. You know what I mean if you ever tried updating a textbox on a background thread.
Below are some of the pros/cons of WPF vs Window Forms from my experience:
Pros:
Much better UI appearance and experience to end users. WPF allows you to have ultimate control of the appearance of any UI element. (e.g. a list box that contains a picture/button/text for each row).
Data binding is amazing. Binding your UI controls in the XAML file to point to specific properties on your ViewModel class, and everything just works. The UI simply responds to any property changes of the ViewModel. Complete separation! You'll really see the benefit of this if you ever want multiple windows/user controls to display the same information simultaneously and automatically keep in-sync.
Everything I've read on MSDN is that Microsoft is putting much more resources into WPF than into the old Window Forms.
Cons:
Big learning curve. Don't be surprised if it takes a couple months before developers with no prior experience with WPF make a somewhat sophisticated UI. It's a brand new technology and there will be a learning curve.
Some common user controls weren't developed by Microsoft yet (e.g. masked textbox, data grid). However, Visual Studio 2010 does come with a data grid and it works well. Also, there are plenty of 3rd party controls on the market.
The best resouces I can think of:
"Pro WPF in C# 2008" - This book is awesome. It's over 1000 pages. It covers almost ever area of WPF. Use it like a reference book. It's straight to the point with easy to understand examples.
Link to Josh Smith's article on the Model-View-ViewModel pattern: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx#id0090016
Like I mentioned earlier, don't get too hung up on someone's version of the M-V-VM pattern. More imporantly, understand how WPF allows you to easily create a ModelView and have the View automatically respond to changes.
Good Luck! You won't regret WPF if you can get past that darn learning curve.
The VS2010 team has kept a blog about obtaining good performance as they switched to WPF.
They have a series, WPF in Visual Studio that offers a few suggestions (especially the second part).
General advice to minimize the time underwater:
Learn data binding as soon as you possibly can. Use data binding in every single prototype you make. Even if all you're doing is playing around with how panel layouts or grid splitters work: put an XmlDataProvider in your window, create XML test data, and bind to it. This is especially useful if you're using Kaxaml to prototype. I don't know how important that's going to be once VS 2010 is in your hands, but if you're using VS 2008 Kaxaml is invaluable.
Read Bea Stollnitz's article on how to debug data binding in WPF. Set your VS environment up so that you can always see the Output window while you're testing your UI.
Use MVVM and data templates from the very start. Pretend that code-behind doesn't exist, and that the only way to interoperate between the UI and the data model is through data binding and commands. You'll back away from this position pretty quickly, but if you make yourself learn this from the jump you'll find everything you do easier.
Pretend that your application needs to be able to run on a 36" widescreen monitor and a phone. Will you use fixed font sizes and measure things to the pixel? You will not.
Learn about the Grid's shared size scope and star-sizing. Those two things mean that you're going to use the Grid everywhere. The answer to the question "How can I get this element to use half of the remaining space on the screen?" is: with a Grid. (However, the answer to the question "How can I get this element to use all of the remaining space on the screen?" is: with a DockPanel.)
Be aware of the fact that WPF is not mature technology, and of the implications of that. It's not that it's buggy (it's not, though there are bugs) or has inadequate functionality (again, there are issues, but not often critical ones): it's that there are a lot of how-to-do-X-in-WPF articles and blog posts that were written before we really knew what was maintainable and what isn't. Validation's a great example. You can find no end of explanation of how to set up validation rules and attach them to bindings. You might not quite so readily find posts written later about why in most real scenarios you want to use IDataErrorInfo. Be even more hesitant about accepting the first answer you find than you normally would.
If you think that composability and dependency injection are obscure architecture-astronaut concepts with little application to real-world software development, get your head straight.
Don't freak out about how complicated dependency properties are. They can do a ton of things, but as a practical matter all you need to think about at first is change notification and value inheritance. Change notification requires a property setter to do something; that's built into SetValue. Value inheritance requires a property getter to do something; that's built into GetValue. The fact that property values can be either local or inherited means that instead of values being stored in fields, they're stored as dictionary entries; if a given property doesn't have a local value (i.e. there's no value for the property in the DependencyObject's dictionary), the DependencyObject looks to the parent to get its value. The terminology's really verbose, but the ideas are very straightforward.
I found this resource that provides several excellent examples.
Microsoft All-In-One Code Framework
Microsoft All-In-One Code Framework
delineates the framework and skeleton
of Microsoft development techniques
through typical sample codes in three
popular programming languages (Visual
C#, VB.NET, Visual C++). Each sample
is elaborately selected, composed, and
documented to demonstrate one
frequently-asked, tested or used
coding scenario based on our support
experience in MSDN newsgroups and
forums. If you are a software
developer, you can fill the skeleton
with blood, muscle and soul. If you
are a software tester or a support
engineer like us, you may extend the
sample codes a little to fit your
specific test scenario or refer your
customer to this project if the
customer's question coincides with
what we collected.
Today is March 12th, 2010. The project
has more than 360 code examples that
cover 24 Microsoft development
technologies like Azure, Windows 7 and
Silverlight 3. The collection grows by
six samples per week. You can find the
up-to-date list of samples in
All-In-One Code Framework Sample
Catalog.
http://1code.codeplex.com/
Consider looking into using the MVVM pattern.