Silverlight Posting Issues – Solved

I encountered some weird problems trying to post Silverligth content in my blog and I can’t find anyone outside of blogs.msdn.com who have done it. My problem seems to arise from a combination of complicated scripts from Microsoft and bad parsing from WordPress not paying attention to the code I was posting. Read on to get an idea of what went wrong. The second half of the post still applies tho – the one about the “old” method. Although it seems irrelevant considering.

Using the iFrame method
Below is a Silverlight application posted using the iFrame method. If you do not see the fancy cirlce animation you need to download the Silverlight RC plugin from Microsoft.

The problem I had comes from the code from Tim Sneath’s blog:

iframe src=”http://silverlight.services.live.com/invoke/32/SlLogo/iframe.html” frameborder=”0″ width=”258″ height=”100″ scrolling=”no” />

It seems WordPress isn’t very fond of shorthand endings like /> but prefers the full ending. Thus the program auto inserted the full iframe close command right after the src call causing the remainder of the code to remain outside of the code. This in turn caused havoc on the remaining page.

Here is the correct code:

<iframe src=”http://silverlight.services.live.com/invoke/32/SlLogo/iframe.html” frameborder=”0″ width=”258″ height=”100″ scrolling=”no”></iframe>

iFrame method conclusion
There’s clearly something wrong with how WordPress parses iFrame code. The iFrame itself appears as it should but it ruins the rest of the code making the remaining page disappear. This problem persists regardless of what content is contained within the iFrame itself. The iFrame method works fine in WordPress as long as you close your <iframe> call with a proper </iframe> call afterwards. Otherwise you end up with a big mess.

Taking the long way round (using the cumbersome original method)
Originally publishing Silverlight apps in a web page was a bit more cumbersome. You can read the full description of the process here. When you post a Silverlight application the “old” way you have to do three things:

Insert script references in the header of the page:

<script type=”text/javascript” src=”http://agappdom.net/h/silverlight.js”></script>
<script type=”text/javascript” src=”CreateSilverlight.js”></script>

Insert html where you want the Silverlight application to appear:

<div id=”Wrapper_SlLogo” style=”width:258px; height:100px; overflow:hidden;”></div>
<script type=”text/javascript”>
var Wrapper_SlLogo = document.getElementById(“Wrapper_SlLogo”);
CreateSilverlight();
</script>

Create a file called CreateSilverlight.js containing the following script:

function CreateSilverlight() {
Silverlight.createHostedObjectEx ({
source: “streaming:/32/SlLogo”,parentElement: Wrapper_SlLogo});
}

If we dissect this process we see what happens:

1. silverlight.js is called. This file is (as far as I can tell) the Silverlight controller. When you create a Silverlight application the file is put in whatever folder you export to but for web purposes it is recommended you use the one posted on the agappdom.net site.
2. CreateSilverlight.js is called. This file contains the source and parentElement parameters showing the browser where the application is located and where to put it (name of the wrapper).
3. The html code creates a wrapper and inserts the object defined in CreateSilverlight.js into it.

For blogging purposes this is pretty much a non-functional process. To make this work in any reasonable manner the source and parentElement parameters have to be defined from within the page itself which means the JavaScript contained within CreateSilverlight.js has to be extracted and somehow inserted into the page itself. Seeing as you don’t have access to the header area in a blog post this means you have to insert the JavaScript in the code itself.

I tried doing this with unimpressive (non-existent) results. I can’t say if this is due to my poor knowledge of JavaScript or if it’s something else. I’m guessing the reason why Microsoft set it up this way to begin with had to do with being able to alter file calls without having to alter pages but that’s just conjecture on my part.

But like I said before: Since the iFrame method works as long as you close your frames properly there is no reason to start screwing around with the more cumbersome old method (unless you really want to that is).