| Comments

after a few inquiries i thought i'd just put together a very simple, very quick demonstration of preparing an existing silverlight 1.0 application for release candidate.  i've posted previously about the preview sdk and breaking changes and this screencast walks through taking two simple samples from the silverlight.net site and prepping them for the release candidate.  you can view the screencast here.

now, i know that every person's silverlight application may vary, but there will be common things you have to do.  this first screencast shows those very common things that likely everyone will have to change.  i'll post up some more conversions of more involved samples shortly.  but for now, this should answer the 'what do i do first?' questions some may have.

these are silverlight 1.0 samples, using visual studio 2005 as the development environment.

HELP: i'm still trying to figure out the best way to deliver media to subscribers (i've posted the screencast on my *cast feed as well), so i've also made an iPod version (m4v) available to anyone.  if anyone has good ideas on enabling a single feed to please everyone without bogging individuals down with formats they don't want/can't use, please let me know -- i'm a noob.

i want to help everyone be successful in preparing your samples/projects for silverlight release candidate.  i keep my contact lines pretty open.  my email and instant messenger information is listed on the contact page of my blog, which i've updated.  i've also added a 'call me' button on the site so that if you want to directly reach out to me, you can.  it connects to me, my cell -- not an office or main line.  call anytime (i can't promise i'll answer at 3am though ;-)).

| Comments

i know i posted earlier with a pointer to the preview sdk over in sneathville, but i walked through the docs this morning and just wanted to re-iterate the need to look at the breaking changes document included in the preview sdk.  why? because when i look at the numerous samples i see that some are likely to be affected.  wouldn't you want your sample to run when the release candidate is put in the wild?  i would.

breaking changes...ugh...they suck.  but bear in mind this is beta and we knew there could be some.  in looking through the docs, i wanted to highlight some that i felt were more common.  the docs do a good job of discussing the change, and showing before/after code.

anyhow, here's my list:

removing 'javascript:' in event handlers

note this applies to if you are coding your even handlers in your xaml like this:

<Canvas x:Name="myButton" MouseLeftButtonUp="javascript:foo" />

you'd want to change that not to include the javascript: prefixer.  personally, i'm of the belief you shouldn't embed your event handlers in your xaml necessarily.  i heard (and saw) a very good discussions on reasons why it might not be a good idea especially if you have designers generating xaml for you.  each generation of xaml from a tool like Expression Design won't 'merge' event handler wire-ups.  what this means is that if you have xaml with event handlers like this and your designer checks in a new xaml file, your app might break because they are using a design tool that may not have functions to enable event handler wire-up in xaml.  i'm babbling here, but note the change if you are.

removing "Sys."

probably going to affect everyone.  instead of Sys.Silverlight.foofunction() you'll need to remove the Sys. prefixer here.  quite simply, the namespace "Sys." was removed in the RC.

using the downloader object

one of my favorite little objects in silverlight.  in the beta bits, there was a third param in the creation that enabled you to choose whether the downloader would perform async or not.  that param is now removed...all downloads are async.  the sdk doc describes a method you can do to trick out the beta bits, but note that the third param is no longer there.

downloader.open("get", file, true) 
downloader.open("get", file)

visibility:hidden is now visibility:collapsed

um, it couldn't be explained any simpler.  hidden and collapsed meant the same thing, so we picked one and kept it consistent...hidden is no longer...use collapsed.

elements in Resources node must be named

good practice anyway that should have been followed, but if you are creating resource storyboards, etc. then you need to name them using the x:Name attribute.  this applies to anything in <Canvas.Resources>

AddEventListener returns a token for RemoveEventListener

basically if you were using removeEventListener before, you'd specify the object and the event handler function.  now, you have to pass a pointer to the token.  so when you add an event listener, you'll get a token as an object return.  you'll then use *that* in the remove command instead of the function name.  something like this:

var enterToken = myObj.addEventListener(“MouseEnter”, myEnterHandler);
myObj.removeEventListener(“MouseEnter”, enterToken);

version property in plug-in creation is obsolete

instead, use isVersionSupported instead.  this is what the new silverlight.js file looks for (note: the new silverlight.js file is also located in the preview SDK).

so there are my key highlights.  there are more, and you really should download the preview sdk and read the docs.  prepare yourself.  prepare your samples (myself included, i need to find the time to go back, but i'd imagine your samples are much more important).  get ready for RC baby!