New Silverlight Write And Win Competition

December 18, 2008


A few months ago as I was getting into Silverlight I wrote an article on building a line of business application in Silverlight and entered it into a competition on the website and came second.  Since then I’ve continued writing additional articles in this series for the website that have been very popular.  Well this competition is being run again, with the details here:

When this competition was run previously the winners were determined by votes from the community.  This time however the winners will be determined by a panel of experts, of which I’ve been invited to be on.  This is quite an honour for me as I hold all the judges in very high esteem (they are the biggest names in the Silverlight community) and I feel privileged to be in their company.

There are awesome prizes on offer so if you’re looking to get into Silverlight or are looking to make a name for yourself there are good incentives to get writing.  I’m not accepting any bribes :), but I will list some of the criteria I’d expect in the articles I give the most points to:

  • - This is an article competition, so the judging will be based upon the article itself – not the accompanying program or code.  You may write a brilliant program, but the program/code should be seen as supporting the article – it should not be seen as the entry itself.  That’s not to say the program/code isn’t important or required, but it’s not the primary focus.  So don’t spend all your time on the code then leave the article until the last minute!
  • - Not all entrants will be from an English speaking background so I won’t place a lot of emphasis on your spelling or grammar.  The article should be easy and enjoyable to read however.
  • - The quality of the article is more important than its quantity (ie. its length).  You might have noticed that my articles tend to be long (the last one coming close to 7000 words) but often shorter is better.  Clarity is the key, and the longer the article the longer you need to hold the reader’s attention for.
  • - The quality of code is not vital, but does indicate your prowess as a developer.
  • - You shouldn’t need to put swathes of code in your article – just note some interesting or unusual snippets worth mentioning.
  • - Talk about your decision making process – why you did one thing and not the other, what alternatives you had, problems you encountered, your experience working with Silverlight as opposed to other technologies, etc.
  • - The topic you choose may be rated partially on its uniqueness and its usefulness to regular Silverlight developers.  Some topics have been done to death (obtaining data from a web service is one of those) so avoid those unless you have something different to say.

These probably won’t be all the criteria, but are just those I can think of off the top of my head.  I look forward to reading your entry!

Building a Silverlight Line-Of-Business Application – Part 5

December 10, 2008

Part 5 of my series on building a line-of-business application with Silverlight is now available on the website here:

The focus of this article is building the data entry form for a product – it sounds simple but there were quite a few issues to workaround.

Building A Line-Of-Business Application Part 4

December 2, 2008

Part 4 of my series on building a line-of-business application with Silverlight is now available on the website here:

It’s been a few weeks coming but there has been a lot of development involved and a few rather difficult challenges to overcome.  The topics I originally intended to cover ended up being split in half due to the huge amount of area that it would have covered (this article is over 4000 words on its own), so for this article I’m focusing just on developing a business object framework and implementing a business object using it.  It’s not overly Silverlight focused but very important to get right when building a line of business application.  I’ll make up for the lack of Silverlight focus in the next article, which will be available early next week when I discuss building a Silverlight data entry form.  All the code for this is already available and the demo has been updated too – you can get to it from the article.

Building a Silverlight Line-Of-Business Application – Part 3

November 12, 2008

Part 3 of my series on building a line-of-business application with Silverlight is now available on the website here:

This article focuses on how the application communicates with the backend database via a WCF service.  The emphasis is on securing your communication and securing access to methods based upon the role privileges of the user.  I also cover sharing business logic between the server and the client.

Thanks to the guys at the SilverlightShow website there is also a live demonstration of the application now too!  Enjoy…!

Building A Line-Of-Business Application Part 2

October 31, 2008

I am now a writer for the SilverlightShow website!  The announcement can be found by following the link below:

I will be continuing my series of articles as detailed by that post, and part 2 is now published.  You can check it out here:

A Wait Indicator In Silverlight

October 9, 2008

For my Silverlight Line-Of-Business framework I wanted a wait indicator much like there is in Firefox or when starting a Youtube video, which could indicate when the application is going off to the server to retrieve some data (or sending some back).  If you don’t know it, the style I’m talking about is eight dots in a circle that light up one after the other around the circle (see the screenshot below).  Funnily enough I couldn’t find any controls out there for this purpose, so initially I just used a text block to notify the user something was happening.  Now that I have a little more time I decided to revisit this and develop my own.  In fact I ended up developing three (that look identical but are implemented differently) in order to familiarise myself with animation in Silverlight, and compare the different approaches.

A bit of an overview of Silverlight animation first (as it pertains to this control with changing the colours of framework elements).  A storyboard is added to to the resources of the user control, and defines the animation per element (ie. each object to be animated – in this case each dot in the circle).  For each element you specify a number of key frames, which essentially consist of a time and the colour the fill of the element should have at that time.  In this case I am changing the alpha value of the fill colour to a specific value and specifying these values in 0.15 second intervals.  In between these 0.15 second intervals the Silverlight rendering engine continues to render the animation, interpolating the value of the previous key frame with that of the next key frame to gradually blend the previous key frame’s colour with that of the next key frame.

I first looked at implementing the animation directly in the XAML using a storyboard with a number of key frames.  I found this approach quite tedious (especially when I ran it and discovered it was animating in reverse – I had to rearrange 64 key frames manually to fix it).  It also blew out the size of my XAML file.  When I started building this control I wrapped the storyboard in an Event Trigger (when the canvas loaded) so that it would automatically start when the control was displayed.  One concern I had was whether the control would continue to animate even when it wasn’t visible (I’m not sure of the answer to this question as yet), and another was raised when in my research I came across this topic in the MSDN documentation that noted (in the remarks) that this approach was discouraged, and to instead put the storyboard in the UserControl.Resources section instead (and manually trigger the start of the animation):

So now I trigger the animation by including public methods on the control to start and stop the animation.  

Note that each dot in the circle is actually white, but we are just adjusting the alpha levels of each dot (blending in with whatever is behind) to give the impression of a moving dot with a trail.  By only altering the alpha value, this means is that you don’t have to use this control on a black background – any backdrop (including graphics) will work and look good.

Now to compare the three approaches.  The animation defined in XAML was painful to implement (it may be easier to do in Expression Blend but I was developing the XAML directly in the Visual Studio editor), whilst it was quite easy programatically (both methods).  Defining the storyboard in both the XAML page and code of course gave exactly the same look and speed as each other.  However manually handling the updating of each “frame” in code produces a slightly slower result (see the sample application to compare) which I found intriguing, despite the same key frame rate – it would be interesting to monitor this difference on a more intensive animation.  Of course I could increase the key frame rate (which is the duration of the animation in this implementation, so essentially reducing the duration) to match but I’m not particularly concerned in this scenario.  The other difference between the storyboard implementation and the  programmatic animation is that they actually look different (as you may note from the screenshot below):

Wait Indicator Sample App Screenshot

Notice when we are programmatically handling the updates that the “lead dot” is the brightest, whilst when the animation is handled by a storyboard the brightest dot isn’t the “lead dot”, but the second dot in the “bright dots” instead (if that makes sense).  This goes back to how the Silverlight rendering engine interpolates the values of the previous and the next key frame – this dot is supposed to be the dullest dot but it knows it is to be the brightest dot at the point of the next key frame so it’s “gearing up for it” by getting brighter as the next key frame approaches.  However in our programmatic updates we are changing the values “discretely” once every 0.15 seconds with no interpolation, thus the lead dot is always the brightest.

Another interesting aspect to compare was the size difference in the class libraries for each implementation.  As compiled DLLs, the XAML version came in at 14,848 bytes, defining the storyboard programmatically came in at 9,216 bytes, whilst the programmatic animation version came in at just 7,680 bytes.  My assumption here is that (and from inspecting each DLL in Reflector) that the XAML file is not compressed when added as a resource to the DLL, while the code in the programmatic version is “compiled” into a relatively compact intermediate language (MSIL) with the comments removed.  Of course this is not the whole story with Silverlight as the DLLs are packed into the .xap file in the main Silverlight project (which is compressed in the zip format).  So to compare this I zipped each DLL and compared the size of each zip file.  The result here was much closer – 3,185 bytes for the XAML version and 2,962 bytes for the programmatic animation – a difference of just 223 bytes, but programmatically defining the storyboard was the largest at 3,863 bytes.  So for this example at least you could say that the impact of each version on your XAML file is negligible.

I would welcome feedback on what approach you think is best and could be considered a “best practise” for implementing animation in Silverlight.  Whereas it was tedious to define the animation in XAML, it’s likely to be more easily modified in Expression Blend later, whilst the programmatic versions will have to always be altered via code.  You have 3 different versions of the control so you can choose your favourite, but until feedback tells me otherwise I will incorporate the version where the animation is defined in the XAML page in my LOB framework.

To use the control in your own projects (whichever version you choose) you could leave it in it’s own DLL (as it is currently) and just reference it from your project, or alternatively just include the .xaml and .cs files in your project.  I recommend changing the namespace (you’ll need to do this in both the .xaml file and the .cs file) as the current namespace name is really designed just for the sample application where the three different versions were running along side each other.  Then reference the namespace in the user control you want it to appear in with a prefix, and then reference and position the control in your xaml layout (remember to include a name for the control using the x:name attribute).  Then in your code behind you can call the Start() and Stop() methods on the control to start and stop the animation.  When the animation is stopped the circle of dots will be hidden, only appearing when the animation is running.

Note that there appears to be a bug in the RC0 version of Silverlight – when you use this control on a surface you won’t see a preview of it in the Visual Studio designer as I collapse the canvas until the animation has been started unless it is being hosted in the designer, using the following code:


which doesn’t appear to pick up the fact that it is in design mode in the Visual Studio designer, so the canvas is collapsed anyway.

As a footnote, after writing the control I was browsing some Silverlight articles about the RC0 release and realised that the new progress bar control could potentially be used as a wait indicator animation also.  This control has a property called IsIndeterminate which if set to True does not render a standard progress bar but displays a moving gradient animation, so I have included this in the sample application for completeness.  I think my wait indicator control looks a whole lot better though (no doubt I’m biased however).

I hope you find this control useful!


Silverlight Line-Of-Business Framework RC0 Update

October 3, 2008

An update to the source code accompanying my article has been added to work with the new Silverlight 2 RC0 release (note it needs to get through moderation, but you’ll know it’s updated when you see a red message at the top of the article).  A few changes needed to be made (primarily to do with control styles) which were throwing exceptions when building/running under the new release.  Thanks go to the guys from the Blacklight project (which I use in the dashboard page) for updating their project to work under RC0 too, so that update has been incorporated into this update.  The main issue I had to solve when updating was the fact that I couldn’t move around or maximise the dashboard panels anymore.  I discovered this was due to the fact that I had put a text block in the “caption” of each panel – whereas previously the mouse down event went straight through my text block to be captured by the panel caption undernearth (to initiate a drag or click), under RC0 the text block was capturing the mouse event and not passing it through.  Adding the attribute IsHitTestable with a value of False resolved this issue.

RC0 brings some new styles and controls with it – the DataGrid now looks a lot prettier so I’ve removed my own styling from the grid in this release.  It still appears you can’t style the selected cell border (well according to the comment above it when I look at the style in the Data DLL in Reflector).  Also with the new styles the line between the rows doesn’t extend across the whole grid width (just to the end of the last column, and some don’t make it all this way either).  I guess that would be OK if you showed the vertical grid lines but I have chosen to hide these to achieve the look I want (or as close as I can get).

On a more positive note, the new rendering such that straight lines are aligned to the nearest pixel creates a much nicer and cleaner look.  You’ll note that on the login screen I now use the new PasswordBox control for the password, and I use the new MessageBox command to notify when an incorrect password has been entered.

View the article here:


Get every new post delivered to your Inbox.

Join 325 other followers