Silverlight Object Tree

In managed code or JAVASCRIPT, you can reference objects in Silverlight's Silverlight object tree during run time. This topic describes how to use the object tree in the Silverlight managed APIs.

Object Tree

The object Tree concept describes how to make objects that are created and existing in Silverlight content at run time relate to each other. A relationship is based on the principle that the object has attributes, and in many cases the value of the property is another object, and this object also has attributes. The object tree has branches because some of these properties are collection properties and have multiple objects, and the object tree has roots because the architecture ultimately has to refer to a single object, which is a connection point between concepts outside the object tree (for example, the browser host or the Silverlight plug-in that displays content).

Although there is actually only one object tree conceptually, the Silverlight API does not expose the complete tree to you. A large number of object tree structures are actually implementation details. You have object-specific properties that affect the child values of specific points in the tree and may report the parent (in most cases, the parent axis is read-only because you typically build the tree up from the root in code or through a XAML parsing process). For example, the Panel has its Children property, which sets the child object. FrameworkElement has parent for reporting the parent. These two APIs are in the base class, so they can be used in a large number of Silverlight objects.

One of the related tree concepts in Silverlight is the visual tree. The visual tree concept refers to the representation of a larger object tree after it has been edited or filtered. The filter being applied is an object that only has a rendering meaning in the visual tree. For example, a collection class is not part of a visual tree, and the visual tree abstracts the collection into a "child" concept. However, if you view the loaded source XAML markup as an approximate structure to the object tree, the visual tree can also contain objects that are not directly displayed. This is because the visual tree also reports objects that are part of a specific control that comes from the applied control template or resource dictionary. The visual tree is used internally for the Silverlight rendering process, but it is often important to know something about the visual tree, for example, to write or replace a control template after the template is applied, or to parse the control instance at run time. For these scenarios, Silverlight provides the VisualTreeHelper API, which examines the visual tree in a way that is more generalized than the actual implementation of object-specific parent and child attributes.

The concept of visual tree also exists in WPF, similar to the visual tree concept of Silverlight. However, a significant difference is that WPF also provides an additional filter or object tree (called a "logical tree") concept. The logical tree concept is related to some property system behavior. Silverlight does not expose this logical tree through helper classes. There are some (but not all) related property behaviors in Silverlight, but because there is no helper API for accessing these behaviors, the logical tree concept will not be useful in Silverlight, so this document does not discuss it. A small compatibility problem raised by the lack of a logical tree is that the Frameworkelement.parent property behavior is different in Silverlight version 3, and it actually reports the visual tree parent.

Object Tree and XAML markup

If you compare the object trees accessed through the Silverlight API with the tree shapes of the XAML markup, they do not exactly match the nodes. This is because XAML is used for markup and is easy to use during tag definition. For example, XAML has the concept of an attribute element that provides guidance about the properties that you can select to set when you find that an element is nested within another element. In the object tree, this is like a property on an object that is set by another object. In contrast, XAML also has the concept of content attributes, where the properties that are set are not even explicitly named in markup. XAML can have syntax that creates objects based on the string value of a property, or provides references to objects that already exist in XAML markup but are defined elsewhere, or that are entirely outside the markup. Despite these small inconsistencies, when you define the user interface in XAML, you define the approximate structure of the final Silverlight object tree at run time.

Referencing object Properties

Regardless of how you get an object reference from the Silverlight object tree, the properties in the managed APIs are exposed directly through the object.property notation, which is related to the core concept of the CLR properties in. NET. Many of the Silverlight 2 properties are based on the concept of dependency properties. Dependency properties and property systems introduce some other possible syntax for accessing properties in different ways than object.property, but unlike attached properties, these properties are not commonly used and are not discussed in this topic. Dependency properties are discussed in detail in the topic Dependency Properties Overview.

Additional properties in the object tree

Silverlight supports the concept of attached properties. From the point of view of an object tree, an attached property is a property that can be attached to any object in the tree, regardless of the object's type (although the object must at least be a dependency object in the Silverlight implementation). Attached property values exist in the object tree, but if you use code to access them, you must use a different syntax than the object.property notation.