MSDN Magazine - November 2008 - (Page 33)

All HTML script objects you manipulate HTML Page from within Silverlight code derive from the Silverlight Page DOM base ScriptObject class. This class defines a Application couple of methods—SetProperty and GetProperty—that all derived classes such as Browser Type Interop Conversion HtmlDocument inherit. Layer What’s the difference between getting and setting attributes and properties? Attributes are always managed as strings; properties are Figure 4 The HTML Bridge in managed as strongly typed values. Silverlight 2 Inside the Browser Interoperability Layer A graphical view of the Silverlight browser interoperability layer and access to the page DOM is shown in Figure 4. Any requests made to any classes in the interoperability layer are resolved through an internal browser host service. Information is marshaled down to the browser’s unmanaged environment and then back to Silverlight. Type differences are hidden and taken care of by the interoperability layer. DOM-level objects are wrapped as managed objects and served to the Silverlight code through a new managed interface—HtmlDocument, HtmlWindow, and the like. Let’s focus on the GetElementById method. As its first step, the method ensures that the code is being called on the Silverlight UI thread. If not, an exception is thrown. Next, a request is made to the underlying browser to get a reference to the specified DOM element. If the request is successful, the method gets an unmanaged reference for the DOM object for which it will create and return a managed wrapper. example) or directly in the Silverlight user interface—it is entirely up to you and your circumstances. The attachment of the event is an operation that occurs through the browser interoperability layer and ends up calling the AttachEvent method on DOM objects. When the browser triggers the page-level event, a call is made back to Silverlight to execute the managed code. When is such a feature helpful in the real world? Silverlight is a product designed to serve up a rich Web front end. You need Silverlight if you need managed code in the browser to do things that a managed language does better and faster than script. Examples of this are code-intensive operations where the speed of a compiled language beats script hands down, or operations that are not available in a functionally limited environment like the browser’s. For sure, you don’t strictly need Silverlight if all that you do is manipulate the DOM. So the ability to handle events in managed code is a very good feature to have, but it does require Silverlight. And you probably wouldn’t want to engage Silverlight only for handling events. Attaching Managed Code to DOM Events Silverlight 2 supplies a variety of APIs for use in making calls to remote endpoints. In Silverlight 2, the HtmlWindow object provides the managed representation of the JavaScript window object. It stores a reference to the DOM object and allows you to drive it with a set of managed methods: Alert, Confirm, Prompt, Submit, Navigate, and even Eval. An instance of the HtmlWindow object is exposed to Silverlight developers through the Window property of the HtmlPage class. The following shows how to display a browser’s message box from Silverlight: HtmlPage.Window.Alert("Hello, world"); A very nice result of the Silverlight and DOM interaction is the ability you’re given to run managed code in response to DOM events. For example, when the user clicks on a button, you can execute C# code instead of JavaScript code. Here’s how you can achieve that: HtmlElement button1; button1 = HtmlPage.Document.GetElementById("Button1"); button1.AttachEvent("click", new System.EventHandler(Button1_Click)); You first retrieve a managed reference to the button (or the DOM element) of interest. Next, you invoke the managed AttachEvent method to register a handler for the specific event. The really nice thing is that the handler is managed code whereas the event is triggered at the browser unmanaged level. For example, getting a GUID is nearly impossible in JavaScript. It becomes fairly easy, however, if you can rely on the power of managed code through Silverlight: void Button1_Click(object sender, EventArgs e) { // Get a new GUID Guid g = Guid.NewGuid(); // Display the GUID in the page user interface HtmlElement label1 = HtmlPage.Document.GetElementById("Label1"); label1.SetProperty("innerHTML", g.ToString()); Let’s explore what happens under the hood of this simple piece of code. The model I’ll examine repeats itself in almost all methods on the HtmlWindow class: public void Alert(string message) { HtmlPage.VerifyThread(); if (message == null) { message = string.Empty; } this.Invoke("alert", new object[] { message }); } } Needless to say, the managed code is a member of the Silverlight page codebehind class. The effect of the operation can be reflected both in the HTML of the host page (as in the preceding msdnmagazine.com After the test on the UI thread, the method fixes the message string if it is null and proceeds to call the Invoke method on the base ScriptObject class. The Invoke method is the bridge between the managed world of Silverlight and the browser. November 2008 33 http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.