×

First time here?

You are looking at the most recent posts. You may also want to check out older archives. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS or email. Thank you for visiting!

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) 
//becomes 
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!



DISCLAIMER:

The opinions/content expressed on this blog are provided "ASIS" with no warranties and are my own personal opinions/content (unless otherwise noted) and do not represent my employer's view in any way.