If you want to know more about Silverlight now, you can pick up Chris Sells and Ian Griffith's book, "Programming WPF: Second Edition". The rough cut edition is available now from O'Reilly with the final print edition coming soon. I wrote the Silverlight Appendix for that book. The Rough Cut includes the Appendix (as well as a great WPF) with its old WPF/E moniker, but the release will include the fully silver-lit version.
I use ListBox's and DataTemplates a lot to show data in different ways in WPF. One of the problems I've faced is how to change the look of the "Selected" element. All the examples I could find assumed you were not using a DataTemplate. Luckily Chris Sells came to my rescue and pointed me at the ItemContainerStyle. Using a Template for the ListBoxItem in the ItemContainerStyle let me control the look and feel of the Selected element (or disabled items) easily.
What I wanted was a nice glow effect instead of the default blue background:
I've been digging a bit into how themes work for a new article. In doing that I wanted to see how WPF used their theme files. Their theme files are stored as BAML in the PresentationUI assembly. As usual reflector came to the rescue with a BamlViewer plugin (available as part of the ReflectorAddIn's CodePlex Project).
If you are in the Washington, DC area (or are close enough to fly), I am coming to teach two courses just after Thanksgiving.
If you're a XAML developer and have proudly stated that you hand-code all your markup, it’s time to learn how to be more productive. I’ve authored a new course for PluralSight. If you have a subscription, you can view it my new “Blend for Developers” course now:
Hope you enjoy the course!
The first topic I am covering is some subtleties of the selector syntax. CSS selectors allow you to pick children, descendants and adjacent siblings. I found that I used descendant selector quite a lot:
I saw a tip by Tim Heuer on a StackOverflow question about how to show binding errors in the Output window of managed WinRT (e.g. Metro-style) XAML projects. Tim mentioned that:
You get this automatically for C++ applications and for managed applications you have to turn on unmanaged debugging to see them.
A lot has been made since a report from Microsoft late last week (http://shawnw.me/HPEh0R) that seemed to say that Silverlight on the phone was going away in Windows Phone 8 (Apollo). I liked a lot of what this article had to say (from e-week):
I also got to discuss fried foods and make fun of Keith. Couldn't have been a better time. Go listen now:
Today Microsoft is finally releasing the new Windows Phone 8 SDK. As I've been updating my Windows Phone book for this new incarnation of the device, I am excited that the SDK is finally going to be available for public consumption.
Even though the new phone has completely changed the underlying operation system to use the same WinRT sub-system that powers Windows 8, the basics of how to build apps on the phone is primarily the same. This means if you have experience building XAML-based projects, you should be right at home with Windows Phone 8.
I am working with a client on an enterprise Win8 app that is for order taking. They have a specific page that they require to be only in Portrait mode while the rest of the app can support any orientation. Since I've done so much Windows Phone 7/8 work I thought this would be simple. Just specify the value on the Page. But this didn't work…
Digging through the docs I found a probable solution: DisplayProperties.AutoRotationPreferences (in the Windows.Graphics.Display namespace). The docs specify that this property can be set with the DisplayOrientations enumeration to specify which of the four orientations to support. The enumeration is a flag so you can combine them too:
I've been digging into some of the open source and 3rd party controls that are becoming available for Silverlight 2. While running into some odd issues with some of them it occurred to me that there are some design guidelines that haven't been well communicated. Back in the early days of WPF I learned (though exactly where is unclear) that every control should support an empty constructor and that all properties (e.g. XAML Attributes) should have a default value. I knew this to be true but I couldn't document where it came from.
So as usual when I am stuck, I contacted Chris Sells as he was my mentor in early XAML usage. He was at MSDN at the time gathering content and helped me get the Data Binding articles as well into the Software Design Review for WPF (then Avalon). If anyone could help me figure out where I learned this, he'd know. He reminded me of the language they use internally: "Create-Set-Use". Essentially this means that the design pattern for controls is that they should work without requiring any properties:
|Using Visual Studio Code for ASP.NET Core Projects (new)|
|Implementing and Securing an API with ASP.NET Core (new)|
|Building a Web App with ASP.NET Core, MVC6, EF Core and AngularJS|
|Building a Web App with ASP.NET5, MVC6, EF7, and AngularJS (Retired)|
|Best Practices in ASP.NET: Entities, Validation, and View Models|
|Front-End Web Development Quick Start|
|Lessons from Real World .NET Code Reviews|
|Node.js for .NET Developers|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||184.108.40.206||Runtime Framework||.NETCoreApp,Version=v1.1|
|App Path||D:\home\site\wwwroot||Runtime Version||.NET Core 4.6.25211.01|
|Operating System||Microsoft Windows 6.2.9200||Runtime Arch||X86|