How can I apply the TypeConverter Attribute ?
In order for your custom type converter to be used as the acting type converter for a custom class, you must apply the .NET Framework “TypeConverter” attribute to your class definition. The Converter Type ’Name’ that you specify through the attribute must be the type name of your custom type converter. With this attribute applied, when an XAML processor handles values where the property type uses your custom class type, it can input strings and return object instances. You can also provide a type converter on a per-property basis. Instead of applying a .NET Framework “TypeConverter” attribute to the class definition, apply it to a property definition (the main definition, not the get / set implementations within it). The type of the property must match the type that is processed by your custom type converter. With this attribute applied, when an XAML processor handles values of that property, it can process input strings and return object instances. The per-property type converter technique is particularly useful if you choose to use a property type from Microsoft .NET Framework or from some other library where you cannot control the class definition and cannot apply a “TypeConverter” attribute there.
Which namespace is used to associate namespace identifiers with element names ? Is there any effect on the attributes ?
There is one more type of namespace declaration that can be used to associate namespace identifiers with element names. This is known as a default namespace declaration which uses the following syntax. xmlns=’<namespace identifier>’ Notice that there is no prefix. When a default namespace declaration is used on an element, all unqualified element names within it’s scope are automatically associated with the specified namespace identifier. Default namespace declarations, however, have absolutely no effect on attributes. The only way to associate an attribute with a namespace identifier is through a prefix. Consider the following example. [XAML] <d:student xmlns:d=’http://www.develop.com/student’ xmlns=’urn:foo’ id=’3235329’ > <name>Jeff Smith</name> <language xmlns=’’>C#</language> <rating>35</rating> </d:student> Here, ‘student’ is from the http://www.develop.com/student namespace while ‘name’ and ‘rating’ are from the default namespace urn:foo. The ’id’ attribute doesn’t belong to a namespace since attributes aren’t automatically associated with the default namespace identifier. This example also illustrates that you can undeclare a default namespace by simply setting the default namespace identifier back to the empty string as shown in the language element (remember you cannot do this with prefix declarations). As a result, the language element also doesn’t belong to a namespace. The syntax for default namespaces was designed for convenience but they tend to cause more confusion than their worth. The confusion typically stems from the fact that elements and attributes are treated differently and it’s not immediately apparent that nested elements are being assigned the default namespace identifier. Nevertheless, in the end, choosing between prefixes and default namespaces is mostly a matter of style, except when attributes come into play.
What are the limitations of Inline Styles and Templates ?
In Extensible Application Markup Language (XAML), style and template properties can technically be set in any one of two ways provided. You can use ’attribute syntax’ to reference a style that was defined within a resource, for example <object Style='{StaticResource myResourceKey}’ …/>. Or you can use ’property element syntax’ to define an inline style for an instance. [XAML] <object> <object.Style> <Style …/> </object.Style> </object> The attribute usage is much more common. A style that is defined inline and not defined in resources is necessarily scoped to the containing element only and cannot be re-used easily because it has no resource key. In general a resource-defined style is more versatile and useful in keeping with the general Windows Presentation Foundation (WPF) programming model principle of separating program logic in code from design in markup. Usually there is no reason to set a style or template inline even if you intend to use that style or template in that location only. Most elements that can take a style or template also support a ’content property’ and a ’content model’. If you only use the logical tree you create through styling or templating once, it would be even easier to just fill that content property with the equivalent child elements in direct markup. This would bypass the style and template mechanisms altogether. Other syntaxes enabled by markup extensions that return an object are also possible with styles and templates. Two such extensions that have possible scenarios include ’TemplateBinding’ and ’Binding’.
How can I create a custom WPF button whose look and feel depends on the Windows desktop theme currently in use. How do I get notified when the user changes the theme?
The WPF theme engine will switch styles automatically for you if you place them in separate ’ResourceDictionary’ XAML files compiled in your application. The files need to be named. themes\..xaml For example, these are the themes that Microsoft produces. themes\luna.normalcolor.xaml themes\luna.homestead.xaml themes\luna.metallic.xaml themes\royale.normalcolor.xaml themes\aero.normalcolor.xaml The case for classic is slightly different. themes\classic.xaml Windows Presentation Foundation does not provide an event to notify the user regarding theme changes. If you need to go beyond what is provided by styles in a ResourceDictionary, you will need to listen to the ’WM_THEMECHANGE’ message in a window hook.
How can I set a ControlTemplate in the style template?
The ControlTemplate specifies the appearance of a Control. If a Control does not have a ControlTemplate, the Control will not appear in your application. The control author defines the default control template and the application author can override the ControlTemplate to redefine the visual tree of the control. A ControlTemplate is intended to be a self-contained unit of implementation detail that is invisible to outside users and objects, including Style objects. The content of the ControlTemplate can be manipulated within the same ControlTemplate only. The following example creates a ControlTemplate for a Button. If you add this to your application as a resource, all the buttons in the application will appear as ellipses but will still function as buttons. [XAML] <Style TargetType=’Button’> <!–Set to true to not get any properties from the themes.–> <Setter Property=’OverridesDefaultStyle’ Value=’True’/> <Setter Property=’Template’> <Setter.Value> <ControlTemplate TargetType=’Button’> <Grid> <Ellipse Fill='{TemplateBinding Background}’/> <ContentPresenter HorizontalAlignment=’Center’ VerticalAlignment=’Center’/> </Grid> </ControlTemplate> </Setter.Value> </Setter> </Style>