Silverlight: Code-behind and partial classes

Code-behind is a term used to describe the code that joins the partial class of a XAML page when markup is compiled for an application. This topic describes the requirements for code-behind classes, the requirement for event handlers defined in code-behind, and the purpose of the mechanisms associated with code-behind, such as the InitializeComponent method.

General requirements

* If a managed application's XAML page has a markup compilation (page Build action and Msbuild:markupcompilepass1 value of custom tool), the root element on the page should declare a x:class. As a fallback, the code-behind file may be limited to the DependentUpon file with the build Operation Compile, as described in the next section.

Code-behind and partial-class requirements

* The partial class must derive the type of the class that is used as the root element.

Note:

Although this is not recommended, you can leave the derivation blank in the partial class definition of code-behind, as long as the tag declares x:class. You should do this only if your page does not have an event handler or other code based logic at all. The result of the compilation assumes that the root of the page is the base class for the partial class, even if it is not specified (because the markup part of the partial class implicitly specifies the base class through its root element tag).

* The partial class must be public. This is required because the partial classes defined by the tag x:class are public when the markup is compiled, so the code partial class must use the same access to join the token's partial class.

* You can choose to omit a namespace as long as it conforms to the way you declare your x:class.

Event handler Requirements

* The event handler written must be an instance method defined by the partial class in the namespace identified by x:class. You cannot qualify the name of an event handler to indicate that the XAML processor looks for the handler in the scope of other classes, nor does it use a static method as an event handler.

* Event handlers need not be public; they can be private or internal. It is generally recommended that you write Non-public event handlers.

* The event handler must match the delegate of the corresponding event. Note that some events use a generic handler for the constrained event data. In these cases, use constraints on the event data indicated in the event signature.

* You can share event handlers for the same event on different objects. If the delegate allows, you can also share the same handlers for different event types. But if you do, your event handler logic should use sender and/or originalsource values to differentiate the event source.

* Specifically for the Visual Basic language, you can associate handlers with instances and events in a handler declaration using language-specific Handles keywords, rather than attaching handlers to properties in XAML. However, this technique does have some limitations because Handles cannot support all the specific features of the event system, such as some routed event scenarios.

Partial class functionality

If you view the partial class that was created from the Silverlight project template, you will see that it starts with the code created by the template, which has a constructor that invokes the InitializeComponent method. You usually do not write InitializeComponent yourself. InitializeComponent is generated by the Silverlight target by code when markup is compiled on the page associated with code-behind. You can view the code-generated InitializeComponent by locating the obj folder for your project after successful compilation. Find a file with. g in its name,. g. Insert between the name of your code-behind filename and the extension. Open this file and view the InitializeComponent definition.

*initializecomponent is primarily used for connection fields, which hold references to individual objects created by markup compilation of XAML. These fields allow code in code-behind to generate Run-time references to any object that provides the Name/x:name property in an object element that defines an object in XAML. If you cannot retrieve objects by name, you need to traverse the Silverlight object tree from the entry point (for example, sender or RootVisual from the event handler) to find a specific object.

*initializecomponent also initializes the rendering of the Silverlight content area when the class is used as a rootvisual.

In the managed API, it is a application object that controls what is displayed in the Silverlight content area, and it must be able to set its rootvisual to an instance of the UIElement class. Therefore, you typically need to x:class any XAML page root declarations that you want to load as a managed, Silverlight-based application content so that rootvisual can reference the class, even if there is no code-behind on the page.