Browse by Tags

• Building Apps
• Custom Controls
• Data Binding
• Digging Deeper
• RC0
• Templates
• User Interface
• XAML

• Data Binding – Data Conversion

  One of the more interesting topics that arise in Data-binding is that of Data Conversion. So much can be accomplished without explicit conversion that it is easy to overlook… until you hit the real world. To see this, I'll make a small modification to the code I wrote for the Silverlight Tutorial on Data Binding . The premise of this simplified example is that you are interacting with a bookstore or a library, displaying information about one book at a time. We assume that you get the book information from wherever it is held via a web service, but that you will create Business Objects from that data, and it is these business objects that you will bind to (this is not the only way to do it, but it is the most flexible). Briefly, the architecture in the original example looked like this What we're trying to accomplish here: bind the data from a Book object to a Silverlight control (textBlock, etc.) The Book class is the business object. It is presumably filled from a call to a web-service, and the properties of the book are bound to the UI objects. As discussed yesterday this is accomplished by setting the binding in the Xaml, <TextBlock x:Name="Title" Text="{ Binding Title , Mode=OneWay }" /> The value that is bound, Title , is a property of the Book class 1: public class Book : INotifyPropertyChanged 2: { 3: private string bookTitle; 4: //... 5: 6: public string Title 7: { 8: get { return bookTitle; } 9: set 10: { 11: bookTitle = value ; 12: NotifyPropertyChanged( "Title" ); 13: } // end set 14: } // end property 15: //... 16: In this case the binding target is a TextBlock also named Title. The Mode on the Binding is set to OneWay indicating that the Title will come from the BindingSource (the Book object) to be bound to the TextBlock, but changes made in the UI will not be sent back to the Binding Source. <TextBlock x:Name="Title" Text="{ Binding Title, Mode=OneWay }" /> Converting Data – Dates for a Calendar If the BookObject had a property for publication date that was of type DateTime, public DateTime PublicationDate { get {//...} set {//...} } You could easily bind it to a Calendar object, <basics:Calendar x:Name="pubDateCal" IsTodayHighlighted="False" SelectedDate="{ Binding PublicationDate }" DisplayDate= "{ Binding PublicationDate }" /> … A calendar control expects a DateTime for its Selected and Display date Dependency Properties. But... Posted Oct 12 2008, 07:29 PM by Jesse Liberty - Silverlight Geek Filed under: XAML, Data Binding, Digging Deeper, Dependency Properties

• Dependency Properties - Precedence

  Today we wrap up dependency properties by talking about one of the most important, though typically invisible aspects: DP precedence order. This is critical because dependency properties, by their nature, are designed to have their final value set from more than one influence (e.g., resources, data binding, animation, etc.) The rule is rigid, sensible and straight forward… Animation uber alles. If there is an animation affecting the value, that will take precedence over all other values Local values over everything but Animation In the absence of an animation, use the local value to override any other values Templates/Styles if no animation or local values If there is no animation or local value, use the value from the template, and if there is no template then from the style. When all else fails, use the default If none of the above apply, use the default value for that type. The Default Value It is the last rule that demands that every type have a default look, and it is because of that rule that you crated generic.xaml – so that if your custom control has a value that is not controlled by an animation, a local value, a template or a style, the Dependency Property System will turn to the default values in generic.xaml and use those. Our First Application With this, we're ready to examine the code to our first application.  As you may remember , we have three projects in one solution.  In CustomControl.cs we declare the visual logic of our control and we will, eventually declare the logic (event handlers, etc.) as well. For now, the listing is quite simple: 1: using System.Windows.Controls; 2:   3: namespace ClassLibrary 4: { 5: public class CustomControl : Control 6: { 7: public CustomControl() 8: { 9: DefaultStyleKey = typeof ( CustomControl ); 10: } 11: } 12: } The simplest logic you can add to get the default style to show. The default style, as you remember is in the file generic.xaml which in turn is in the Themes folder, 1: < ResourceDictionary 2: xmlns ="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 3: xmlns:x ="http://schemas.microsoft.com/winfx/2006/xaml" 4: xmlns:controls ="clr-namespace:ClassLibrary" 5: xmlns:vsm ="clr-namespace:System.Windows;assembly=System.Windows" 6: xmlns:d ="http://schemas.microsoft.com/expression/blend/2008" 7: xmlns:mc ="http://schemas.openxmlformats.org/markup-compatibility/2006" 8: mc:Ignorable ="d" > 9: < Style... Posted Oct 02 2008, 10:39 AM by Jesse Liberty - Silverlight Geek Filed under: User Interface, XAML, Digging Deeper, Custom Controls, Dependency Properties, RC0

• Dependency Properties, Continued

  First, a hearty thank you to " obsid " who wrote a great comment noting that by using reflector you can find that the documentation is not yet updated and System.Windows.PropertyMetadata's constructor is overloaded. While I am a fan of writing reflective programs (see chapter 20 Programming C# 3.0), for those of you who don't particularly want to dive into this somewhat obscure topic, an easier proof of obsid's point can be obtained in Visual Studio by opening the Object Browser and searching for PropertyMetaData where you will find the following:   (Image modified) As you may be able to see, there are five overloads: a default constructor, one that takes an object, another that takes an object and a callback, a fourth that takes an object, a callback and a "CoerceValueCallback" and finally a constructor that take a callback alone. Highlighting any of these causes it to be summarized in the associated window in the object browser. Nifty tool. A Note on Feedback: I would encourage feedback and corrections, but you are not shy; so keep it coming. As for the specific note about default values, please be assured that issue will be covered when Dependency Property Precedence is covered. Advantages of Dependency Properties In the previous discussion, I talked about the "cost" of DPs; specifically the learning curve. The advantages manifestly outweigh the cost and today I'll begin to discuss what you get for this somewhat byzantine system. The short answer is that Dependency properties were invented to support four forms of "late binding" for properties that are not easily supported when a property is backed by a field: Resources Data binding Styles and Templates Animations Support for each of these can be accomplished in other ways, of course, but the Dependency Properties system is faster and more efficient than the alternatives. Note that the Dependency Properties system was not invented for Silverlight, it was originally invented for WPF and then adapted for Silverlight. In fact, some of the breaking changes from Beta2 to RC0 are in service to bringing the Silverlight version more in line with the WPF version. Resources Resources are typically specified as child elements of a page root element, or of the application (e.g., in App.xaml) Data Binding Data binding works through a specific markup extension syntax in XAML, or the Binding object in code. With data binding, the final property value determination... Posted Oct 01 2008, 11:03 AM by More Signal, Less Noise Filed under: XAML, Digging Deeper, Dependency Properties, RC0

• Dependency Property System – Deeper Dive Part 1

  On the 17th I began a discussion of Dependency Properties, but as I said then, there is more to say. This central concept to Silverlight Programming has traditionally been taught as an advanced concept.(Can we have traditions in a product that hasn't really been released yet?) And to some degree, with good reason: you can pretty much ignore the Dependency Property System until/unless you're writing custom controls. Here are three reasons not to: 1. They're fascinating 2. They explain a lot about how things work 3. They are critical to creating your own custom controls Okay, the real reason is #1; they're just interesting. There are a couple ways to approach Dependency Properties. Most of us approach them practically, to accomplish a specific goal at first ("How do I wire up a DP in this custom control?") and then later, we return to understand the entire system into which they fit. It is the purpose of today's column to begin that second stage: examining the system as a whole. An Adventure in Spelunking the Dependency Properties System We need to start by acknowledging a few somewhat surprising facts: The folks who created WPF and Silverlight made some rather radical (and I would argue technically courageous) decisions: they said "the current properties are inadequate for our needs, and we're going to add a new layer on top that will not break the underlying layer but that will give us tremendous additional options." Thus, the Dependency Properties system is really a radical extension to the CLR and to that which is available in C++, Java, or even pre-WPF C#/VB.NET. Then the folks at Silverlight chose which parts of the system they would use, which they'd adapt and which they'd leave behind based on optimizing for the needs of Silverlight rather than just for pure isomorphic consistency. Controversial but highly defensible decisions, and ones that will give us early headaches trying to understand all of it, but long term benefits. The biggest problem, of course, is that figuring out what is really going on can be a bit problematic, especially right now. This particular moment in history is a documentation purgetory. The WPF books are excellent but not everything they say applies to Silverlight The Beta2 chm file and help files are very good but now partially obsolete The change document is helpful but not guaranteed to be complete Full documentation of Dependency Properties was never a priority as it was considered... Posted Sep 30 2008, 10:07 AM by More Signal Filed under: XAML, Digging Deeper, Custom Controls, Dependency Properties, RC0

• Dependency Properties – Background for Custom Controls

  In  a previous post I began talking about Custom Controls, and I will continue that discussion over the next few days and weeks even as I start producing videos on the topic. It turns out that the more you look at Custom Controls, the deeper you get into the Silverlight UI architecture, and there is much to see. As an example of this phenomenon, in writing about Custom Controls, you quickly realize that sooner or later you must describe and explain the Dependency Properties System in Silverlight. This brings great joy to my heart, because it is one of the more interesting and one of the less discussed aspects of Silverlight programming So this evening I'm going to leap ahead (a bit out of order) and introduce this system, though by no means cover it in depth in one blog post.  (Written late Tuesday, posted early Wednesday) Understanding Our Roots Traditional C# classes consist of Methods Events Member Variables Properties You can easily view these in the Object Browser in Visual Studio (all but the member variables, which are almost always marked private and not shown). [Note, image cut down to save space] C++  did not have properties (nor running water, nor electricity). Back in those dark days, if we wanted to provide access to the value of a member variable, we created methods to do so. Thus, you ended up with funny looking code like this: overallApproval = jesse.GetApprovalAverage() + tim.GetApprovalAverage(); Rather than the more natural, overallApproval = jesse.Approval + tim.Approval; Properties were brilliant . They looked to the class author just like methods, but they looked to the class consumer just like variables. This was crucial. The class author was free to continue to obtain the actual value from backing variables or anywhere else: 1: private double approval = .4; 2: public double Approval 3: { 4: get 5: { 6: if ( currentViewer.ID == "ScottGu" ) 7: return .9; 8: else 9: return approval; 10: } 11: } In practical experience, most properties are backed by member variables, though that is by no means universal – some are backed by values in persistent storage, and some are computed dynamically. But some very large percentage are backed by member variables, which is why Auto-implemented properties were invented (and they are also brilliant). Prior to C# 3.0 my code was peppered with annoying properties that looked like this: 1: private int myMember; 2: public int MyProperty 3: { 4: get { return myMember; } 5: set { myMember... Posted Sep 17 2008, 06:00 AM by Jesse Liberty - Silverlight Geek Filed under: XAML, Digging Deeper, Templates, Building Apps, Custom Controls, Dependency Properties