If an application runs on Windows Vista today, there’s a very strong likelihood that the application will run unchanged on Windows 7.There are 3 key steps that every application author has to take care to still further diminish the risk of any application issues: Blogs:
Windows 7 Application Quality Cookbook. This is the ultimate guide to changes in Windows 7, offering 80+ pages of detailed guidance on the various different edge cases that might cause an issue with your application. (A quick perusal of the document will allay any fears of widespread change – unless the likes of ‘removal of Microsoft Agent’ is of major concern to you.) Using this document as a checklist, you’ll be able to very rapidly identify anything that you should take care of.
Download(and read!) the Windows 7 Developer Guide. This guide helps in building applications on a solid foundation; enable richer application experiences.
Search this Blog:
Windows 7 for Developers
WPF Lookless Controls
WPF Lookless Control Model = Styles, Templates and Triggers
A WPF control does not include a hardcoded visual representation. Rather, the default visual representation is specified in XAML in a completely separate theme assembly from the class that implements the control's logic. This separation of code-based logic from visual representation (the control's look and feel) is what makes the WPF control model so powerful. We refer to this approach as a "lookless control model".
Why - Two big reasons: design and reusability.
Developers and designers can work side by side to simultaneously create powerful and visually stunning applications, with each person doing what they do best. A developer can implement an application's logic at the same time that a designer creates the application's look and feel. To a great degree, it is the lookless control model that enables this new workflow.By introducing a lookless control model where the visual representation of the control is specified apart from the control's code, we are able to put the visual design into the hands of a qualified UX designer, where it belongs.
The second big reason for separating a control's visuals from its code implementation is reusability. In the past, if you wanted to have two buttons with different visual appearances, you had to create two separate button classes with the correct rendering code baked into each class. Both classes contained the same basic button logic. They both provided a "click" event in response to the appropriate mouse or keyboard user interactions. The only difference between the button classes was in the rendering logic. By moving the visual representation into XAML and out of the control class, we allow a single Button class to be reused wherever we need to support a Click interaction. The button can have whatever visual representation the designer wants to create. The developer no longer needs to be involved in the process of redefining a button's visual representation.
Ref:
Lookless Control Model -
http://www.drwpf.com/blog/Home/tabid/36/EntryID/53/Default.aspx
Top Ten UI Development Breakthroughs In Windows Presentation Foundation -
http://msdn.microsoft.com/en-us/magazine/cc163662.aspx
Styles and triggers in WPF -
http://www.microsoft.com/
Using Templates to Customize WPF Controls -
http://msdn.microsoft.com/en-us/magazine/cc163497.aspx
Designing Lookless Controls in Windows Presentation Foundation -
http://www.devx.com/dotnet/Article/34564
WPF Apps With The Model-View-ViewModel Design Pattern -
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
WPF MultiThreading -
http://www.a2zdotnet.com/View.aspx?id=93
Creating a look-less custom control in WPF -
http://www.codeproject.com/KB/WPF/WPFCustomControl.aspx