A love-hate relationship is a personal relationship between humans or organizations, or figuratively between a human and an inanimate object, like a computer, a field of study, a body of ideas, or a profession, involving simultaneous or alternating emotions of love and enmity. This relationship can, but does not have to be of a romantic nature.

I have a such a relationship with the evolving technology currently called SilverLight. Originally codenamed “WPF/e”, Microsoft’s new “Flash-killer” has been both a bane and a boon at times. I’m just going to address some of my own personal gripes with it…and some of the cool things I’ve been able to use it for. While I know that SilverLight isn’t actually aimed at me because I don’t seek to use it for (buzz word alert) RIAs and such, I’ve found other uses for it that I believe are valid. For instance, if you’ve ever used JavaScript graphics (which is extremely slow and bloats your code because you place a whole bunch of div tags in you page) then SilverLight is a great alternative. Not only is it a million times faster, it’s pretty simple to use/integrate with. The major reason I see SilverLight taking off/or at least taking some of the steam out of Flash’s engine is the fact that it’s so easy to integrate with…and of course with the 1.1alpha…CLR support. Using myself as an example…I don’t know ActionScript…and at no time have I even bothered to take the time to try to extend myself and learn more than just the basic stuff. But I do know JavaScript…and I’m much more willing to use SilverLight because of it.

Major Gripes

1. Where’s my right click support? — Just like with Flash, the creators of SilverLight saw fit to enforce their own version of branding by making the right mouse click completely useless except as a plug for their own technology. Rather than giving developers the ability to provide their users with a more intuitive/rich experience…ie. no context menu functionality (short of pressing the control or shift keys), they’d prefer to display a link back to the Microsoft SilverLight homepage. I personally think it’s shameful…and a waste.
2. Where’s my Button control? — I just don’t get why SilverLight is missing a button control (I don’t count the one in the sample pack…it’s not a “part” of the “technology”…if you get my what I mean). It would be extremely useful to have a button control…and they even saw fit to illustrate how one could create one using Canvas, Rectangle, and TextBlock controls. The only problem is that this requires unnecessary “labor”. I personally think that it should be a part of the platform. But a) I don’t work for Microsoft and b) even I did…I probably wouldn’t be making decisions like that.
3. (I may be wrong on this but…) Why is there a complete lack of versioning support? — This gripe may be misplaced…because I just may be ignorant of how WPF/e (SilverLight) work. I was completely pissed off the when I “upgraded” to the 1.0beta of SilverLight and none of the code for my WPF/e stuff would work. It wouldn’t even start. Hey…I know the install tells you to uninstall WPF/e CTPs, but to me this highlights a major issue. Will I have to upgrade my app every single time that there’s a SilverLight update? If so, then what’s the point of using SilverLight? Maintenance should be a minimal concern. Hopefully there won’t be any breaking changes in the way they do things from now. But who knows? For example, if you look at the .NET Framework v1.0 – v2.0 had a lot of breaking changes; code that compiles under 1.0 might not compile under 1.1 or 2.0. Will SilverLight travel the same route — or will they just bloat the API by adding features rather than changing them? And since this is all JavaScript compile time == run time, so yeah…that’s a major concern for me. The client updates his/her SilverLight…and my code no longer runs — not good.

Major Loves…(ha)

1. The Downloader Object — I love the Downloader Object. It is by far the most useful thing to me as a developer (so far). I basically just use it to access my application “gateways”. Some people use web services…I personally like to make ASPX pages that know how to read/write JSON fluently (maybe not the “smartest” or standards compliant thing…but it makes it easier for me to debug) . Same thing I was doing before people jumped on this whole AJAX bandwagon…it just makes it a lot easier by having an object that encapsulates all that for me.
2. Speed – I love the speed of using SilverLight. As I said before, the problem with JavaScript is the fact that it can’t “do graphics”. That’s not what it was made for. It’s a scripting language. Sometimes as a developer you want to have dynamic graphs and things like that but you leave yourself with basically two or three options. Either have a server-side process that makes the graph and saves it to an file of some kind (or you store it in an object w/o saving it to disk), or figure out how to draw the same thing pixel by pixel. You can even try mixing server/client side creation/display…but the gist of it is…compared to just scripting the display…it’s a little more work. SilverLight trumps pure JavaScript in the graphics/speed department — and I like that.
3. Easy translation of existing skills — SilverLight is just like the other XAML-based technologies that have come out. It makes development a lot easier, and helps you leverage you skills if you can use the same language/code to target completely different platforms. If you can use/learn XAML, that means you know or will know how to make applications for desktops (WPF), Internet Explorer (XBAPs/SilverLight), and other platforms(SilverLight). Just by changing the main Window object to a Pane or Canvas…the same code can target just about everything (as long as you don’t use too many platform specific objects). Another reason why SilverLight may become a Flash killer.

Edit: OMG…the C# Express version is 864 MB big. Why is everything so huge? There’s no way this thing is going to fit on a single DVD when it’s done…not if it’s still 5.4 GB big — for the Professional Edition. I wonder why it’s so huge?

The first thing we need to do, is fire up our copy of Microsoft Expression Blend (at the time of this writing…I’m using Beta 2). We want to create a new Control Library…so I recommend you select that as your project type, and name it something like CustomControls. Ideally, you’ll probably want to reuse your custom Expander control, and you’ll probably want to add more controls to this library. So once that’s done, open up the XAML view of your first control, and you should see something like this:

Now, in a previous tutorial, I made it a point to say that you can inherit your custom User Control from ANY control. By default, you inherit from UserControl, but in this case we want to inherit from the Expander Control. Why? – because we just want to customize the current Expander Control…only adding minimal improvements. So what you need to do is replace the UserControl markup with Expander. Be sure to remove the Grid Control from the XAML, because you’ll want to leave the Content of your control empty. I suggest that you also rename your XAML and code-behind files/classes to the name that you intend to give the Control. I named my control CustomExpander, and my partial class to CustomExpanderControl (remember that your class and control’s names have to be different). Another thing that I’m going to make specific to my control, is its initial size and ExpandDirection. I want my control to expand to the right. So after making the necessary changes, my XAML looks like this:

Now that we’ve finished with that, you need to add some static animations and triggers to the control. The reason why we want to do this is because it’s easier to manipulate something that already exists, rather than instantiating it every time we need use it. So, the first thing we need to do is add some triggers to our control to handle the Expander.Collapsed and Expander.Expanded events. So switch to your Design View, and add some triggers by click on the “Add Event Trigger” button.

After you’ve added triggers for both of these events, let’s go ahead and edit our animation timelines. Go ahead and create keyframes for what you want your custom Expander Control to expand/collapse to. You need to create a keyframe for the beginning of each animation, as well as the end. For the sake of this tutorial, these values need to be reflections of each other (i.e. if you want to Collapse the width from 150 to 25, then you need to also make the control expand from 25 to 150). This is very important, because the way we’ll handle editing the animation properties depends on it. For this tutorial, I’ve decided to expand the control from a width of 25 (collapsed) to 150 (expanded), and the opacity to go from 25 to 100. I’ve also made my control take 1/2 second to animate. It doesn’t matter if you use the same values, just as long as they’re consistent.

So after you’ve edit your control’s properties, added triggers, and create some animation timelines — we’ve done the “hard part”, and it’s time to edit the code-behind file in order to expose some properties that will make our control easier to use and customize. So go ahead and close out of Expression Blend (we’re done with it), and open your project in Visual Studio. Now, I mentioned auto-collapse as a feature that we’ll want to use in our control, as well as the ability to enable/disable animation. So the first thing we need to do is add some private member variables to our controls.

The TriggerCollection is for saving our control’s triggers — I’ll explain why later. We’re going to use the timer for timing how long before our control auto-collapses and the staysOpen member will control whether or not the control auto-collapses at all. This should give you an idea of “how” we’re going to do what we need to do. But there’s still some more customization features we can/will add. First of all we need some way to edit the animation timelines — so let’s expose some private properties that will help us do that.

We expose these two properties, because they give us direct access to our two different animation storyboards. The properties below control the width of our collapsed/expanded animations.  They reflect the values that were stored in the static keyframes we created earlier. This is the reason why created a start frame, and an end frame in our timeline. These are all the private properties we need to expose some public properties.

Now, let’s list our public properties. It should be fairly obvious how these properties can/will be used. The Width properties control how big the control will be when expanded/collapsed — and the Opacity properties specify the control’s opacity during these two states. By editing these programmatically, one can control the animation of our control with a relative amount of ease.

Now it’s time to add the “mack-daddy” of properties…and explain why we have a TriggerCollection.

This property will control whether our control animates or not. The way we want to control this is by adding/removing triggers from our control. Rather than adding/removing the actual storyboards, or animation timelines — we can just remove the events that call them. This makes our job alot easier. So first we’ll save our triggers in a TriggerCollection at the time our control is instantiated. Then when animation is disabled in the control, we’ll remove all the triggers. When animation is re-enabled we just add back the triggers we already saved.

Those are all the properties we need to declare, but we still need to enable the auto-collapsing function, as well as save the triggers. To enable the auto-collapsing function, we want the control to start “timing” on a MouseLeave event, and stop/reset on a MouseEnter event. This brings up something very important to developers new to .NET Framwork 3.0. Since we’re going to use a Timer to kick-off our auto-collapse, the Timer is going to need a way to invoke our Collapse event from a different thread. In .NET 2.0, all controls had an Invoke method they inherited for these kinds of cross-thread actions. But .NET 3.0 has taken that out of the control scope. Instead, to access objects in the UI thread, you have to used the Dispather object. (Go here for more information: http://msdn2.microsoft.com/en-us/library/ms591593.aspx)

So let’s go ahead and instantiate the objects that haven’t already been instantiated…and go ahead and create our various event handlers. This is done in our control’s constructor.

Now that we’ve done that, the first thing we need to do is create a delegate for making this auto-collapse call. So we need to add a delegate type like this one to our class:

Simple enough? Now, let’s create a function that will set the IsExpanded property to false, as well as call this function (using a delegate) from our Timer’s Elapsed event handler. Take a special note of the way you use the Dispatcher.Invoke method.

All that’s left for us to do now, is to simply handle the MouseEnter/Leave events. Basically, when the mouse leave the control, if animation is enabled, and StaysOpen is false, then we’ll start the Timer. When the mouse enters the control, we’ll stop the timer. If the Timer is already stopped, then it won’t throw an error, or affect the controls state at all.

Now we are done. Just compile your project, and start using this cool custom Expander. By default, the control will animate with whatever animation properties you’ve assigned it. But these properties can all be accessed/changed programmatically throught the code-behind find or through XAML. By exposing these properties, they can also be edited in Expression Blend, under the Miscellaneous tab. Now isn’t that great?

I think the biggest obstacle in a project like this, is the fact that I don’t really know what I’m doing. If this was a project to create an enterprise application…or create some other “normal” desktop application, I’d be done already. The fact that emulation is a completely new endeavor for me, and the fact that there aren’t a huge number of howto’s for emulating Sega’s Dreamcast make it preeetty hard to plan effectively…or in my case…at all. But anyways…hopefully I won’t give up on this, and make this into something intellectually lucrative.

Because it’s an XML-based language…it gives the developer and end-user easy to use, yet very powerful control over customization/theming and templating. I’m not going to get into alot of detail, but believe me when I tell you that this can/will radically change the way alot of people handle the UI side of things. Custom controls are a given in today’s enterprise world because they’re scalable and reusable. They save you tons of  time because you don’t have to re-invent the wheel everytime you go to make a new application. It’s the essence of object-oriented programming.

Now, imagine that every control at your disposal, even the ones straight out of the box, are custom controls. That’s what WPF gives you. You can apply branding/theming to every button, in every application you make just by including another XAML file or two. And not only that, you can make all you controls “act” a certain way in a multitude of different situations. Some may argue that this functionality (or some subset thereof) was already available in .NET 2.0…or on some other platform…or in some other progamming language/environment…but for those people like me (targetting a platform that has about 98% market share…or work in a corporate environment where all machines are running Windows XP) WPF and its child technologies are a very powerful and scalable solution. It gives you great user experiences in and out of the browser, and helps you practice the “Law of Least Privilege” with it’s sandboxed XBAPs (the web applications formerly known as XAPPs).

Now like I said, this is a great technology…and it’s been around for quite some time. But guess what…almost nobody I know uses it…and tutorials are a little scarce. But if you’ve made it to this blog…obviously you’ve just started to use it…or have been using it…and you need a little help with one of the most obviously “cool” things that you don’t get out of the box with WPF. Now…the Expander control is very cool when you first include it in you application. It’s basically a collapsible menu of sorts. If you’re like me, you not only expected it to animate in/out, but you also probably expected it to retract when you moved your mouse off of it. BUT…no such luck. The whole purpose of XAML/WPF is to give you what’s necessary(the bare minimum) …and let you build the rest. So let’s get started with the animation bit, shall we?

Before we start, I’m going to assume that you’re using Microsoft Expression Blend (currently in Beta 1) and/or Microsoft Visual Studio. There are a couple of different ways to actually handle the animation of the expander control. First, let’s take a look at the programmatic way to handle the expander control’s animation.

Programmatic animation is alot more intuitive to developers coming from a strong .NET background…or those who don’t like firing up another application just to quickly apply an animation effect. The main drawback with programmatic animation is that it doesn’t animate to scale — meaning that if your user changes the size of the application window, the animation isn’t scaled to meet the change in window size (unless you scale your animations by using percentages). Make sure to include the System.Windows.Media.Animation namespace in your code-behind file. 

First you need to add event handlers for the Collapased/Expanded events of the Expander control.  Here, we have an Expander Control named expMenu.


public Window1()
{
     InitializeComponent();
     //add handlers for the expanded/collapsed events of the expMenu Control      expMenu.Collapsed += new RoutedEventHandler(expMenu_Collapsed);
     expMenu.Expanded += new RoutedEventHandler(expMenu_Expanded);
}

Next you simply need to create two DoubleAnimation objects that animate the Width property of an Expander Control. So first, we place the necessary DoubleAnimation in the Expander.Collapsed event handler.


void expMenu_Collapsed(object sender, RoutedEventArgs e)
{
     DoubleAnimation dblAnimation = new DoubleAnimation();
     //set the width that we want the expander control to
     //have when animation is complete
     dblAnimation.To = 35;
     //set the duration of this animation - generally 1/4 or less looks best
     dblAnimation.Duration = new Duration(TimeSpan.FromSeconds(.25));
     //begin the animation on the width property of the expMenu control
     expMenu.BeginAnimation(Expander.WidthProperty, dblAnimation);}

You should place the same thing in your Expander.Expanded event handler, but change the DoubleAnimation’s “To” value to the fully expanded width. After that, compile & run your application and your Expander should animate. You can also use this method to animate the Opacity of the Expander so that it’s less visible when collapsed. You can reuse the same DoubleAnimation by using the Expander.OpacityProperty in the Expander.BeginAnimation method and setting the the “To” property to the appropriate value.

So that’s programmatic animation. Next…I’ll blog about using Expression Blend to do the same thing.