Modified on 2008-Nov-16: (See notes added about Vista at the end)

Here are my PowerPoint slides and demo code used in my Silverlight Debugging presentation at the 2008 Silicon Valley Code Camp at Foothill College on Saturday November 8, 2008.  The demo code is three separate VS2008 solutions in a ZIP file.  They were built with the SL2RTW Silverlight Tools for VS2008+SP1.  Below are screen shots of two of those demo apps.

Little Silverlight "bootstrap" loader
demo (loads bigger Silverlight app).

Performance demo (MaxFrameRate).

Thanks for coming!

Alan Cobb

--------------------------------------------------------------------------
2008-Nov-16: Some added notes about problems on Vista:

During my Code Camp session on 2008-Nov-08 I was running on XP.  Afterward I tried re-building and re-running the demos under Vista.  I ran into two problems worth mentioning:

1) After you download the ZIP file containing these demos, Vista (or XP too depending on your settings) is suspicious of any of the files in the ZIP.  You will get warnings from VS2008 when you try to build the demo projects.  To prevent those warnings, do the following:  Right click on the ZIP file in Windows Explorer.  At the bottom of the "General" tab in Vista there should be an "Unblock" button.  Press the "Unblock" button and the warnings for this particular ZIP file will stop.

2) Getting Fiddler to spy on traffic to localhost when running on Vista:
One standard trick to allow Fiddler to spy on HTTP traffic to localhost is to add a "." at the end of localhost.  For example:  http://localhost.:4444/LittleLoaderAppTestPage.html  When I tried that on Vista I got an error message from Fiddler. In order to make the "localhost." trick work on Vista I needed to change one of Fiddler's settings.  Specifically: Tools / Fiddler Options / General tab. Uncheck the "Enable IPv6" checkbox.  I don't know why that works, but it did for me.  I learned about this Vista fix here.

Summary:
This post discusses one short-coming of the NBCOlympics.com Silverlight video player and shows a simple CSS tweak you can make to force the video to completely fill the IE7 browser window, even when running full screen on a big monitor.

Stock player before tweaking.
(Fixed-size 848x480 pixel video)

After CSS tweaked to force full-screen.

Some people have criticized [1][2] aspects of the Silverlight "HD" video player that NBC is using to show the Olympics on the Internet (only available in North America). One of the biggest irritations is that there is no stock way to make the video window fill a large monitor. This has led some people to erroneously suspect this may reveal a technical limitation in Silverlight's ability to "stretch" video.

Since I have been working on my own SL video player demo app, and since I'm interested in SL debugging, I looked at the site's code to see if it could be "coaxed" into full screen mode. It turns out that just changing two lines of CSS styling is all it takes to go full screen.  If you only want to see the "how to tweak" details, you can skip the following "why?" section.

Background: Why no full screen mode?
If all it takes to go full screen is changing two lines of CSS, then clearly the fixed 848x480 video window was a deliberate design decision. Why would Microsoft and NBC make that choice? Tom Taylor of Microsoft has offered at least a partial explanation. He says one factor was that when you scale the video to fill a larger screen the compression artifacts are more apparent. That is true. Another, probably more important, factor is: "...restrictions placed on the usage of full screen video by the IOC".  Tom says it is "absolutely false" that NBC made the choice out of fear that a "too good" player might undermine their cash cow of conventional TV broadcasts of the Olympics. Whether that's true or not, some early reports suggest the large amount of video on the NBC site actually helps increase the TV audience (at least with a somewhat neutered SL player).

Tom says "most people have 1024x768 monitors or less", but according Browser News, "~91% of page accesses" come from browsers with resolutions of 1024x768 and higher.  Even if the average user is still at 1024x768, it isn't that hard to create a liquid layout that adapts as well to 800x600 resolution as to 2560x1600.  One of the biggest attractions of Silverlight and WPF for me as a developer is that they are vector based (highly scalable), and have strong support for liquid layouts.

Workarounds:
Regardless of why they chose a "small" fixed layout, how can we get the scalable, full-screen behavior that many of us want?

Simple non-programmer fixes:
Actually, the simplest ways to get full-screen behavior don't require any programming: As discussed in the same silverlight.net forum thread, one solution is to just temporarily drop your display resolution down to 1024x768. The disadvantage is that it also forces the OS and all your other programs down to that low resolution too.

Probably the best fix is to download Firefox 3 (ironic from MS's point of view) and use its "zoom in" mode to expand the Olympics video to full screen. Unfortunately, IE7's own "zoom in" mode has an issue that prevents it from working well in this case. Yes, IE7 will zoom in on the video, but the banner ad on the same page periodically shifts to the right for some reason, pushing part of the video out of view.

More technical fixes:
Since this is a technical blog, and most of us are "devs", we'll look for a more programmer-level fix. Actually, both the following fixes are quite simple once you know what to tweak.

Technique #1: Add a personal style sheet rule:
For this one I just added the following CSS rule to the personal style sheet I use with IE:

The CSS "id selector" #videoPlaybackHost refers to the DIV element holding the Silverlight control that displays the video.  I've replaced the fixed 1002 pixel width with a width of 105%.  That makes the video stretch to fill the entire width of the browser window, regardless of how small or large you make it.  What a concept! :)  Although the 200% height seems odd, that was what worked on my 1600x1200 display.  You can tune those percentages, or switch to large fixed numbers like a 1000px height, to suit your particular monitor size.

After you create or edit the custom style sheet, you need to restart IE7.  Also, when the smaller browser pop-up window that holds the video appears, you need to press the "ENLARGE VIDEO" button on the player and press F11 to make that browser window border resizable.

Technique #2: Create a "bookmarklet" to tweak the DIV style to full screen:
This second technique was suggested by "slyi" on the Silverlight forums.  Although creating a personal style sheet is easy, this is even easier (thanks slyi).  I had never created a "bookmarklet" before, but it was simple enough.  For those of you who haven't used bookmarklets, the basic idea is to use the text of a little Javascript program as the href address in a hyperlink / bookmark.  When you click the link, instead of openning another web page, your few lines of Javascript run.  

First create a regular favorite (IE) or bookmark (FF).  Then right click on the favorite and select "properties".  Now paste the following single long line of Javascript into the URL field:

Finally, once the video player window is open and you have clicked the "ENLARGE VIDEO" button, you just click the bookmarklet containing the above code and it will force the video to fill the browser window.

One problem is that the video player window normally opens with just a title bar, but no menus and hence no bookmarklets/favorites to click.  To get around that in IE7 you can copy the URL at the top of the video window into the address bar of a full browser window.  Or just click this URL to a random video to get you into the player.  Now your bookmarks menu should be available.

Doing the analysis with IE Developer Toolbar or Firebug:
I used the IE Developer Toolbar (IEDT) add-on with IE to come up with the above simple CSS fix.  You can use Firebug on Firefox to do the same thing.  IEDT and Firebug both show you the element tree for the host HTML page.  You can browse down to the nested DIVs containing the Silverlight control and interactively tweak their CSS styles!  

This screen shows IEDT in action, after I have tweaked the DIV's width and height on-the-fly.  And yes, they really do have cheerleaders at the Olympics.

The more conventional "full screen" mode of Silverlight:
Finally, although I like this liquid layout technique for going "full screen", Silverlight also supports a more literal full screen mode, where the Silverlight app can immediately jump to fill the entire screen without any surrounding browser chrome.  There is a whole section in the documentation about it.  Most other Silverlight video players offer that capability.  Like this player sample on CodePlex. 

Alan Cobb

Motivation:
What if you want the user of your Silverlight app to be able to change some properties of your UI dynamically on-the-fly? For example, it would be nice to let your user set the FontSize to their liking at runtime and have that new size used by all controls immediately.

One way to do that is with data binding and a shared "app-global" "binding-relay" object. The graphic below shows the UI of this sample app and how its elements are indirectly connected with data binding via a "binding-relay" object. This general technique has been described by other people as part of larger articles (see for example, here and here [both links are slow]), but here I want to emphasize just this one technique. Although it has some disadvantages, it's a useful pattern to have in your toolbox.

My sample app is split into two sections. The group of "controller" elements in the upper half is used to dynamically change the properties of the "controlled" TextBlocks in the lower half. The graphic below shows the UI of this sample app and how its elements are indirectly connected with data binding.

Live copy of this sample app (SL2B2 version)

Sample source code as zipped VS2008 solution
(After you unzip and rebuild it, remember to again set the HTML page in the web project as the Start Page before you run it with F5.)

How it works:
We start by creating a custom class that exposes the global properties we want to support. For example, "double dFontSize". In this sample the class is called CBindingRelayClass_ApplicationWideSettings. We create a single shared instance of that class by instantiating it in the App.Resources section of our App.xaml. Now multiple elements anywhere in our application can bind their FontSize properties as targets to the dFontSize source property on the global object. This class must support the INotifyPropertyChanged interface. That's how the binding system is alerted when one of our global properties is changed. Then the binding system "relays" that change out to all the bound targets of that global source property. That's why I call it a "binding-relay" object.

We drive changes to the global dFontSize property with a Slider. The Slider is TwoWay bound back to the global binding source object. The binding mode for the Slider must be TwoWay in order for it to drive the value of the dFontSize property (changes flowing from target back to source). Normal OneWay binding only moves changes in the other direction, from binding source to target.

So those are the basic "tricks" behind this technique.

More implementation details:
It's easy enough to use TwoWay binding to make the Slider drive a property like dFontSize because it has the simple type double. But what about a type like FontFamily? In this sample I use a ListBox to choose the FontFamily. But instead of TwoWay binding, I fall back on an "old school" event handler. In the ListBox.SelectionChanged event handler I "manually" instantiate a new FontFamily object based on the selected line in the ListBox and assign it to the oFontFamily property on the global "binding relay" object.

What about the Slider driving the oSolidColorBrush property on the global object? There I also go "old school" rather than using TwoWay binding. In the Slider.ValueChanged event handler I "manually" translate the Slider Value (which ranges from 0x000000 to 0xffffff) into an RGB color, use that to instantiate a new SolidColorBrush and finally assign that to the global oSolidColorBrush property.

In theory we could have used TwoWay binding to drive the values of both these more complex properties. That would require writing value converter classes that implement IValueConverter. For example, we should be able to write a value converter that translates back and forth between the types double and SolidColorBrush. My preliminary experiments under SL2B2 with TwoWay binding using value converters for more complex types didn't work, so I haven't shown that here.

Disadvantages:
Although using a "binding-relay" object does let you dynamically change properties in real-time, it also has some disadvantages. One burden is just that you need to define and instantiate the binding-relay object somewhere. In contrast to the current Silverlight version, WPF's binding system allows you to directly bind one element to another, without needing a "relay" object in between (See for example). So in WPF you could directly bind the FontSize property of one element to the output of a Slider control. Another drawback is the extra binding XAML you must add to every control that consumes the "dynamic property". For example: FontSize="{Binding dFontSize}".

New "property value inheritance" of font properties in Silverlight:
This technique's ability to dynamically control the font properties of many target elements simultaneously seemed a bit more impressive before SL2 Beta 2. But now SL2B2 has introduced more "property value inheritance" to Silverlight, something which WPF already broadly supports. Most of the font-related properties (like FontSize and FontFamily) have been moved to the Control class in SL2B2. Now those values are "inherited" by the child elements inside a given control. This means you can set the FontSize and FontFamily once on a UserControl and those values will cascade (like in CSS) down to the child elements. To demonstrate that you can add these bound properties to the XAML that defines the Page UserControl:

FontSize="{Binding dFontSize}"
FontFamily="{Binding oFontFamily}"

After that change when you vary the FontSize Slider, the text size changes everywhere on the Page, not just in the lower half. We are still using the "binding-relay" object, but now it is unnecessary to duplicate the same binding XAML on every target element.

Alan Cobb

A great tool for debugging Silverlight 2 cross-domain problems is the free "debugging proxy" tool called Fiddler.  Fiddler acts like an "HTTP sniffer".  It lets you watch as your browser has HTTP-conversations with servers.  This post is a very brief example of using Fiddler to "spy" on Silverlight 2 as it looks for cross-domain policy files.  For the demo I'm using ScottGu's Silverlight 2 Digg client demo.  Scott now has downloadable Silverlight 2 sources for his demo here. (I did a translation to WPF in a previous blog article.)

If you download and build Scott's SL2 demo and have Fiddler installed, you should be able to capture a "trace" of the HTTP requests made by Silverlight to the Digg site, and the responses.  In the attached screen capture of Fiddler you can see Silverlight first try to open clientaccesspolicy.xml from Digg's site and fail, but then try and succeed to open crossdomain.xml.  You can also see the contents of crossdomain.xml that were returned.  The '*' is allowing any domain to call Digg's APIs.

When it comes to testing some unknown site to see if it has cross-domain policy files, one technique is to just hit that domain with your browser and see if it can find those files.  For example, if you type this URI into the browser: http://services.digg.com/crossdomain.xml, the browser will successfully find it and show you its contents.  So their "welcome" sign has been lit.

Alan Cobb

I'm doing an "Introduction to Silverlight" presentation tomorrow (2008-Mar-07) at SD-West-2008 in Santa Clara, California focusing on the .NET based Silverlight 2.

Here are my PowerPoint slides (5.3MB).

Alan Cobb

The main point of this article is to make my reformatted, more debuggable version of Silverlight available to other people for download:

      For 2007-09 v1.0 SDK:  Silverlight_DebugPretty_V10.js 
      For 2007-09 v1.1 SDK:  Silverlight_DebugPretty_V11.js

Background and explanation:
As you probably know, Silverlight.js is a helper file that all Silverlight applications are required to use when starting up.  To make it download faster it has been "minified" into a single line of JavaScript 7000+ characters long.  That's OK for production use, but it makes the source code unusable for debugging.  For debugging you want to be able to use Visual Studio to single step through readable, understandable source code and look at variable values and stack traces.

The 2007-07 version of the Silverlight SDK included such a reformatted Silverlight.js (even including some descriptive comments [gasp!]), but I couldn't find one in the 2007-09 versions of the SDK.  So I made the ones linked to above. 

To do the reformatting ("pretty printing") I started with a free trial copy of the commercial Polystyle code-reformatter product.  That turned the single JavaScript line into about 400 readable lines, with proper indenting.  I followed that with a little hand editing to visually separate the individual methods with lines of asterisks.  One could go even further and add some descriptive comments.

Once you are a old hand at JavaScript and Silverlight you probably won't spend much time looking at Silverlight.js.  But if you are like me, with a background in C# and C++ you may initially find JavaScript's behavior somewhat "odd" and mysterious.  It can be instructive to single step through the startup code in Silverlight.js.  See how one of the first steps is to "instantiate" all the methods of the Silverlight object so they can be called later?

Minification and obfuscation:
I found out via petemounce on the Silverlight Forum (see: http://silverlight.net/forums/t/5697.aspx) that there are tools available specifically for the task of minimizing the size of ("minifying") your JavaScript or HTML.  See: http://www.julienlecomte.net/blog/2007/08/13/introducing-the-yui-compressor/

This is closely related to the task of obfuscation, in which you try to make your code harder to reverse engineer.  Deliberately debugger-unfriendly.  See: http://yuiblog.com/blog/2006/03/06/minification-v-obfuscation/

Hi,

This is my new blog.  Interesting Silverlight, WPF and .NET technical content to follow...

Regarding how this blog was designed and implemented:
My visual design priorities for this site's HTML/CSS were a liquid layout and good tolerance of text resizing.  Similar to http://news.google.com.

As the footer shows, this blog is currently implemented with dasBlog 2.x running on ASP.NET 2.0.  I'm currently hosted on GoDaddy and happy with them.  To get the visual look and liquid resizing behavior I wanted, I needed to modify some of dasBlog's ASP.NET C# code as well as the page templates and CSS.

Alan Cobb