Are there any "undocumented features" in Silverlight?

Question

I was wondering if there are any features in Silverlight 2 or 3 that aren't documented or are hidden very deep in the framework? Stuff that can be very helpful in some cases, but can be a pain to find. Are there any "hidden" gems?

I'm thinking about stuff you normaly don't find in tutorials and in demos. For example, finding information about the operating system the Silverlight Application is running on thru the System.OperatingSystem class.

Answer 1

The public APIs are well documented and I haven't seen any hidden methods from browsing through Intellisense. I have however found a lot of useful information from decompiling the libraries with Reflector and searching through the source. One example was searching for an implementation of ICollectionView - Silverlight exposes this interface but doesn't provide a public implementation of it. While searching through the code for the DataGrid I noticed that it was using an implementation of ICollectionView and found a full implementation of the interface in the ListCollectionView class. Of course, the class is marked protected and I couldn't use it from my code but I was at least able to read the source as guidance before creating my own implementation. I don't think there are many hidden features in SL, but reading the code can provide a ton of information.

Answer 2

In silverlight itself, like JC said, is pretty tight. Microsoft is trying to rush as well as put out clean code. The Stand alone (like AIR) in 3.0 is pretty cool. I see a lot of potential in the ListCollectionview class for in memory database style transaction processing without reinventing how we program. The tools from the vendors like Telerik, DevExpress, and the Silverlight Toolkit really do show us a glimpse at the potential of where we are going with silverlight.

HTML 5 looks like mid 90's shockwave to me. I hope that silverlight seriously catches on.

Answer 3

Things we found out during Silverlight development (...and after googling for a long while). Whether those are features, or something else is left as an opinion for the reader:

• All the sizes and locations of UIElements are stored in a 32-bit integer of which 16-bit is the signed integer part, and of which 16-bit is the fractional part. Not funny since we had a very large WPF Canvas which broke without rewriting
• We needed fullscreen mode for data-entry our application. However, fullscreen disables user input from the keyboard (except for some keys) we found out! No data-entry in fullscreen (because of security concerns, it appears)!
• To subscribe to the left mouse button is easy. For the right mouse button you need some browser specific Javascripts hack to capture that and pass to the Silverlight app. No fun.
• You cannot subscribe to DataContext changed events. You need to create a new DependencyProperty attaching to changes in the original DataContext and during creation you can set your handler to react indirectly on DataContext changes.
• Don't use Firefox when debugging Silverlight. Using Internet Explorer makes debugging possible.
• If you cannot attach to your program (breakpoints show up as empty red circles in VS2008 instead of filled ones), do clear your Internet Explorer cache. This might help.
• You can edit XAML with intellisense in Visual Studio. However, the intellisense only works with the slow XAML preview window enabled (split view). But this slows down Visual Studio immensely.
• When porting an application from WPF to Silverlight as we did, throw out all XAML and start a new. Trust me. Especially if you're using Blend as an editor: this one throws in attributes for fun even when not used.
• Try to do as little in XAML as possible. XAML has no debugging capabilities when instantiated resulting in obscure exceptions during instantiation.
• This is also true for data Bindings: they tend not to give exceptions, but log to the Debug window of Visual Studio without a way to attach a debugger at that point.
• WPF/e object creation is very expensive. You should not create more than several hunderd WPF objects since this will make applications too slow. Instead, create your own WPF object cache to reuse WPF objects of the same type for different purposes.

Answer 4

Just a couple to add:

• You cannot select padding or ciphermode for AesManaged in Silverlight, so you will have to use the default. Padding by default is PKCS7 just like in your C# code, but cipher mode is CBC.

• In order to set the width and height of the container, make sure everything has loaded - pick your slowest loading thing and do the following (for a bitMap Image (for example)):

  void bitmapImage_DownloadProgress(object sender, DownloadProgressEventArgs e)
  {
      if (e.Progress == 100)
      {
          Dispatcher.BeginInvoke(delegate()
          {
              imageHeight = backgroundImage.ActualHeight;
              imageWidth = backgroundImage.ActualWidth;
  
  
          var host = HtmlPage.Document.GetElementById(
              HtmlPage.Plugin.Id);
          //Use CSS to change the size of the plugin.
          host.SetStyleAttribute("width", GetAppWidth());
          host.SetStyleAttribute("height", GetAppHeight());
  
  
          imageDimensionsLoaded = true;
          rootPage.UpdateLayout();
          positionOverlays();
      });
   }
  
  
  }
  

Answer 5

As of Silverlight Beta 4 there is no public DataContextChanged event.

The Microsoft Connect bug report has been marked as 'Fixed' but with no indication of what that actually means.

In the meantime you need a workaround such as this one - which is very simple and should be easy to switch out if Microsoft ever actually makes the event public. It uses the method described in Rutger's answer but it very modular and easy to replace in future.

Answer 6

Undocumented Silverlight Feature - ETW tracing

ETW Tracing