.NET Reflector is a great tool. I would wager that most of our loyal readers (all 6 of them ;-) ) already know all about .NET Reflector. But just in case, here is how to get it:http://www.red-gate.com/products/reflector/ In addition to spying on the code parts of Silverlight assemblies, or verifying the object model of your own custom assemblies, a great little trick you can use with .NET Reflector is to access the genuine XAML that represents a library's generic.xaml file. The generic.xaml file is sometimes referred to as the "theme file", because of its history in WPF, but in Silverlight the concept of "theme" is something of a distraction, so I won't use that word again. I usually just call this thing generic.xaml. Generic.xaml contains the initial and default template values for all the code-defined controls in the assembly that are supposed to have a UI representation. Basically generic.xaml is an enormous ResourceDictionary, where each keyed item in the dictionary is a separate Style. Each such style is keyed by the TargetType of the control that the style and its enclosed templates are applied to at run time. So, if you have a copy of generic.xaml, and you use a Find operation to find the string key of a type you are interested in, you have a view of the XAML that composites that control by default. Using the default XAML template is the best possible starting point for recreating the template that you might use to retemplate a control. It can also be a useful starting point if you have subclassed the relevant control class, and you want your subclass to be just a slight variation on the behavior and UI representation of an existing control. Before I get around to touting .NET Reflector, I will first put in the plug for the MSDN Silverlight documentation, which can provide much of this same information but in a different presentation. The default templates for every control we document from the reference perspective actually exist as part of the MSDN documentation. Start from Control Styles and Templates in the TOC. Open up the topic for the particular control you are interested. Take for example TextBox. Each of these pages contain the following information: * Named parts of the control, if any. Knowing the named parts is important because you must replicate that part (with the same name) in order to not break the base control class' contract behavior.
* Named states of the control that the default template defines. The existing named states each communicate information visually to the control user. Generally any new template should provide states for any state name/case that the default template provided, for the best user experience. You can also add your own new states, if that makes sense based on extra elements or behavior that you add to the template, or a subclassed control.
* The complete XAML of the default template. This includes the XAML of the parts and states; the listings at the start of each Styles and Templates topic is just to make that information easier to find and have a chance to explain the function and purpose of each part/state. Read more: Silverlight SDK
* Named states of the control that the default template defines. The existing named states each communicate information visually to the control user. Generally any new template should provide states for any state name/case that the default template provided, for the best user experience. You can also add your own new states, if that makes sense based on extra elements or behavior that you add to the template, or a subclassed control.
* The complete XAML of the default template. This includes the XAML of the parts and states; the listings at the start of each Styles and Templates topic is just to make that information easier to find and have a chance to explain the function and purpose of each part/state. Read more: Silverlight SDK