Browse by Tags

• Breaking Change
• Custom Controls
• Dependency Properties
• Digging Deeper
• How Do I Videos
• Isolated Storage
• Recommended Resources
• Templates
• Tools
• User Interface
• XAML

• Custom Controls – The Dénouement

  Over the past month I've posted half a dozen min-articles about creating custom controls that can interact with the Visual State Manager, and the underlying engine that makes it work; especially Dependency Properties and the Parts and States Model . Intro to Custom Controls Part 1 Intro to Custom Controls Part 2 Creating Custom Controls Generic.xaml Dependency Properties Part 1 Dependency Properties Part 2 Dependency Property Precedence With this background, we're ready to move on to the steps of implementing visual states in your custom control. The key concept that we've been building to is this: there is a strict separation between the logic of your control, and the visuals of your control. The place that this becomes most clear is often when you click on a control. Visually, many controls respond to a click with some form of visual change. Logically they respond with some behavior- or they raise an even that allows "listeners" to respond. Keeping these separate is key to the Parts and States model. The Custom Control that we're going to create (in a whirlwind fashion here, more carefully and slowly in a forthcoming tutorial and videos) is derived from Control, draws its own shape, is designed to be skinnable, and supports the parts and states model. As such, it defines three CommonStates Normal MouseOver Pressed It also defines two CustomStates Normal On Notice that because the StateGroups (CommonStates and CustomStates) are orthogonal, there is no problem having a NormalState in both. State Changes. The custom control appears as a grey ball when it is in its Normal CommonState and in its Normal CustomState, but its visual appearance changes noticeably when it moves into any of the other states. In addition, I've added a template that changes its appearance in its normal state and in its other visual states and to cap it off the control publishes an event for when it is clicked allowing the page that houses the control (templated or not) to respond to the click. <whew!> While we'll save the nitty gritty for the tutorial and the videos, the point to focus on here is this: how does the control convey its visual contract to the Visual State Manager (and to Expression Blend?). That is accomplished using attributes . These are placed above the definition of the CustomControl and constitute the contract between the control and the Visual State Manager; they assert the state groups and the states within those state groups... Posted Oct 09 2008, 06:47 AM by Jesse Liberty - Silverlight Geek Filed under: XAML, Digging Deeper, Templates, Custom Controls, RC0

• Silverlight Controls, Controls Team, and Testing

  This blog will rarely be the place for breaking news, but there are two related pieces of information I want to ensure you know about at the risk of repeating news that has been blogged by others.  First, Shawn Burke’s team has announced their intention to release the following new Silverlight controls at PDC 08: DockPanel WrapPanel ViewBox Label HeaderedContentControl Expander TreeView NumericUpDown AutoComplete Accordion Really more important than this list is the fact that Scott Guthrie (ScottGu) has asked one of our smartest and most productive managers, Shawn Burke to create and build the Controls Team (as Shawn explains here ). Their new release model is well worth reading about, and they have some very exciting plans for building controls that will make coding in Silverlight that much easier. I’m particularly interested in how the Label might interact with the PresentationControl, how the TreeView andExpander might interact with data in a client-only architecture and how the new layout controls will change the look and feel of Silverlight applications. More than any of that, I’m eager to set aside some time to play with the Unit Test Framework they’ve developed that Shawn introduces here ,  as that may well become a central application building tool. I highly recommend reading Jeff Willcox’s writeup of his testing tool; don’t let this slip by without taking note.   You’ll find everything you need to get started with the test tool here including additional tutorials, videos and so forth.  Enjoy   -j Posted Oct 04 2008, 04:58 PM by Jesse Liberty - Silverlight Geek Filed under: Recommended Resources, Tools, Digging Deeper, Custom Controls, RC0

• Template Browser – an indispensible tool

  One way that many developers like to create styles and templates for controls is to modify the existing styles and templates. An unusual feature of Silverlight is that every control in the toolbox is lookless – its appearance is determined by its own generic.xaml, just like the custom controls you create. Finding this generic.xaml can be a bit tricky, as it is stored in a specially named resource file, but it is all documented on MSDN . That would be pretty good, but David Anson (aka "Delay") has created a wonderful desktop tool for inspecting (and copying) the styles and templates of the Silverlight controls (Click on image for full size) This is a really nice piece of work, allowing you to expand and collapse and spelunk the templates and styles and also to copy either or both to the clipboard to bring into your own code. I've added the circles and arrows to point out that the outline of elements is entirely collapsible and that the bottom of the browser offers a number of useful options. I find this particularly useful in finding best practices for working around apparent limitations such as the changes to the ContentPresenter discussed on Sept 28. Note that the link to the standalone tool includes the source code – but the program was written in WPF, not Silverlight. If you want the Clickonce version, you'll want this link. Posted Oct 03 2008, 09:46 AM by Jesse Liberty - Silverlight Geek Filed under: XAML, Recommended Resources, Digging Deeper, Templates, Custom Controls, RC0

• 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

• Isolated Storage – Actually, It's Easy

  I'll be doing a video on how to use isolated storage, and there is quite a bit to it, but the fundamentals are surprisingly straight forward.  The idea of IsolatedStorage is to provide your Silverlight Application with access to the user's disk, so that you may store… well, whatever you like when your application is not running. Whether or not you have access, and how much space is allocated is entirely under the control of the user. In many ways, IsolatedStorage is the next generation of cookies: you can store more, more robustly, with greater precision and control. A full blown usage of IsolatedStorage might involve the creation of files within a directory structure (all of which is obfuscated on the user's hard drive), quota allocation and the storage of binary data. You might use this to store far more than window positions or the user's current "state" within your application; you could conceivably store parts of your application or other binary data to speed up or otherwise enhance the user's experience. At its simplest though, using IsolatedStorage can be as simple as writing to one of two pre-defined dictionaries: IsolatedStorageSettings.ApplicationSettings or IsolatedStorageSettings.SiteSettings.  In both cases, the key is defined to be a string, the value to be an object. You grab a reference to the dictionary and the IsolatedStorage system ensures that your application's dictionary is isolated from the dictionaries of other applications. SiteSettings are, as you might expect, shared among all applications on a site. To be more exact, Applications settings are per-application, per-computer and per-user while SiteSettings are  per-domain, per-computer and per-user. If I have IE open to two sites, http://microsoft.com/redmond/example1.xap and http://microsoft.com/redmond/example2.xap, these applications will share site settings since they share the same domain, but different application settings. This can get tricky, though. If my browser is open to http://microsoft.com/redmond/example1.xap and http://microsoft.com/boston/example1.xap it turns out they share the same site (microsoft.com) but not the same application as these are independent .xap files as determined by the full path. But now we're deep in the mud, and at a high level, getting started with IsolatedStorage is easy, which is the point of this posting. The application I built (total development time 10 minutes) looks like this, Clicking... Posted Sep 29 2008, 10:06 AM by More Signal Filed under: Digging Deeper, RC0, Isolated Storage

• RC0 & ContentPresenter

  The breaking changes document points out that ContentPresenter now derives from FrameworkElement and thus loses 18 public properties  as well as TextAlignment, TextDecorations and TextWrapping. All of this calls for a bit of rewriting if you've used this powerful and useful control, and there was a request in one of the internal discussion lists that this be called out to developers; hence this blog entry. Serendipitously, I have a video that uses the ContentPresenter control . The ContentPresenter control is the enabling control behind entering "Content" rather than text in the standard Button, CheckBox and so forth.  Until RC0, you could have set the fontsize, FontWeight, etc. in the ContentPresenter itself, though that never would have been good programming practice, as it always made more sense to leave that for the client (the programmer using your control. Thus, in my template, I set few properties on the ContentPresenter itself, and when I use the control that the ContentPresenter is part of (the Button) I can set the characteristics of the content, which are then passed to the ContentPresenter. This will continue to work in RC0 Let me be explicit, if you used ContentPresenter as intended (note the Beta documentation which states "Typically, you use the ContentPresenter directly within the ControlTemplate of a ContentControl to mark where the content is to be added.") then you would probably not have used any of the properties that are no longer available to you, as you would have wanted, as I did, to leave that flexibility to the consumer of your control. On the other hand, if you did use those properties, the fix is fairly simple, you just remove the properties from the content control, and if you need the property set, you set it when you call the control An example will make this explicit.  Assume you define your button template in App.xaml as follows (the following listing is abridged): 1: < ControlTemplate x:Key ="RoundButton" TargetType ="Button" > 2: < Grid > 3: < vsm:VisualStateManager.VisualStateGroups > 4: </ vsm:VisualStateManager.VisualStateGroups > 5: < Ellipse > 6: </ Ellipse > 7: < ContentPresenter Margin ="0,10,0,0" x:Name ="RoundButtonContent" 8: RenderTransformOrigin ="0.5,0.5" 9: HorizontalAlignment ="Center" 10: VerticalAlignment ="Center" 11: FontFamily ="Comic Sans MS"... Posted Sep 28 2008, 09:29 AM by More Signal Filed under: How Do I Videos, Templates, Breaking Change, RC0