Sidebar vs WPF vs 64bit

For a current project/prototype I’m working on – I’m developing an ‘Aussie’ Sidebar Gadget for Vista – and one of the requirements/desires was to use WPF instead of DHTML/jscript. (so we can give our friends in NZ some competition – who have been blessed with a whole stack of amazingly cool gadgets for launch).

Being a glutton for punishment – and having a dangerous obsession with getting ‘Unsupported Scenarios’ up and running (WPF is not officially supported for Sidebar use) – I happily accepted this project. To make things a little more difficult for myself – I also decided I wanted to develop this on my main work machine – which happens to be running Vista 64 bit.

While I do get into all sorts of grief using 64bit (ie. Software/Drivers not working) – I still think its the best option – and as a general rule of thumb – if I get it working in 64bit – then it’s going to work in 32bit (although in some cases a specific 32bit build needs to be recompiled where 32bit specific DLL’s are used). If I did it the other way around (develop on 32bit and port to 64bit) – then I’ve got a much greater chance of finding showstopper bugs (as in most cases feature/compontent ‘X’ will be designed primarily for 32bit users and sometimes no 64bit equivelent will exist) – and would in some cases need to completely rewrite/rearchitecture parts of the program to use a different 64bit supported technique.

So anyhow in terms of my journey with WPF and Sidebar – I was luckily not the first to try this <phew> – and there was some really useful blog posts out there to get me started.

First up in the reading list were these invaluable posts from Karsten Januszewski on IRhetoric Blog :

WPF Vista Gadgets – Part 1: Using XBAP and IFRAME

WPF Vista Gadgets – Part 2: Using ActiveX

Inter Process Communication Between Applications and Vista Gadgets Using WCF (Part 1)

Inter Process Communication Between Applications and Vista Gadgets Using WCF (Part 2)

Chuck Sterling (from Microsoft Australia) also upped the ante – and published a fantastic step by step article (with source) and Video on creating an ActiveX based WPF Gadget in VB.

Armed with all this useful information, examples and background – I set out to do some testing of my own.

If you check out the links above – you’ll notice there are two techniques being presented for hosting WPF’s in Sidebar – one is to host it inside an ActiveX control and expose it to the HTML page as Windows Forms User Control – and the other is to deploy the WPF as an XBAP (XAML Browser Application) and host it within an IFRAME tag (or alternatively – directly hosting a loose XAML file).

I should also mention that WPF/E is also a potential way to get WPF going in Sidebar – however since there’s no ‘code-behind’ functionality with this – I won’t consider that here.

There’s a few pro’s and con’s of using either technique mentioned above –

ActiveX: 

Pros- Easier communication/Tighter integration with HTML page/javascript due to COM properties/methods being exposed by ActiveX.  Faster Initialization time / (possibily) better performance.

Cons- Doesnt appear to work on 64bit (even though Sidebar actually runs as a 64bit process). Harder to Deploy as ActiveX needs to be properly registered (if being installed locally – developer would have to right .MSIsetup package) – and hence you may not be able to package it into auto installed .gadget file.  More Dev Overhead (need to create wrapper project for your ActiveX and do some additional footwork to get Class/ProgID’s all lined up)

XBAP:

Pros- Works on 32bit and 64bit. Easy to deploy (can just include .XBAP file in .gadget package and ClickOnce will handle the rest). Less dev overhead (no additional host ActiveX project is required). XBAP can be remotely hosted – so gives you the ability to issue updates to the end user without them needing to do anything tricky.

Cons- Slower to initialize then ActiveX (and much longer on first run). Communicating with your XBAP from your HTML/Jscript layer is very limited (unless you go to effort of writing WCF communication components).

 

Since I wanted to get this going on my 64bit dev machine – and also didn’t think other potential 64bit end users should be prevented from using this gadget – I decided to go down the XBAP path. It also made sense to have some easy/automatic mechanism available to seemlessly update the XBAP if new versions were created (via ClickOnce).

Some of the downsides of using XBAP’s are mentioned in Karsten’s posts above – and are mainly due to some unsavoury and clunky behaviour experienced when you add/remove the gadget to sidebar (and also reported to cause issues when you start up or shut down the machine once its added). This is partly due to background dlls being loaded for WPF (PresentationHost etc) – which can put a strain on your system when its busy doing something else (such as starting up your desktop after logging in).

Additionally – one downside of XBAP was that when initializing the gadget in the ‘docked’ area in Sidebar (which is 130px wide) – the XBAP ClickOnce screen looks pretty unreadable.

 

After storyboarding a few ideas/mockups (in a graphics package) – I came to the conclusion that I where I really needed/wanted WPF was in the flyout window (which provided infinitely more room for cool stuff) – and not the ‘docked’ gadget itself (which would be subtle and require less ‘wow’ factor – and of course not chew up any CPU). I also realized that given the small size of the docked gadget – any funky effects required could be quite easily achieved with animated gifs/pngs and javascript. 

Using WPF only the flyout also had a number of upsides – and with XBAP’s – it solved a number of the issues mentioned above –

– Because the gadget doesn’t display its flyout (the WPF bit) when added/removed from Sidebar (or when machine is shutdown or started) – the WPF PresentationHost doesn’t need to be initialized/unloaded at critical times. (and hence eliminates the ‘glitch’ factors).

– When you do launch the flyout window (by interacting with the docked gadget) – the system is generally in a ‘less’ critical state and it can be loaded cleanly and quickly. (and similarly the flyout can be closed quickly).

– If it’s being loaded for the first time by ClickOnce deployment (or updated) – then the flyout window is large enough to see the progress/status dialog. (as opposed to this screen being garbled in the docked gadget).

So anyhow I’m sticking with this technique (‘XBap on the flyout’) – and hope I don’t find any issues as I get closer to finishing this. (but so far so good!).

 

One hurdle I encountered along the way – was that initially I couldn’t get it going on my development machine. Normally I run Sidebar on my 2nd (2 of 3) monitor – and when the flyout was launched – the Xbap didn’t appear. I noticed however that if I immediately played a Video within the XBAP – then I could actually here it (just not see it). 

Chuck Sterling came to the rescue and pointed out that this was likely a ‘rendering’ issue – and that he’d had similar problem with a NVidia 7300GS based machine.  So a little while later I thought I’d try running Sidebar via my primary monitor (as some other applications sometimes had issues on all but my primary monitor) – and low and behold it all worked (so very much indicates something going amiss with the graphics drivers). I do have the latest NVidia drivers from Windows Update (which appear to have this issue) – at least this is something that might be fixed in future driver updates.

So now I’m up and running and it’s full steam ahead on this WPF gadget (and now concentrating on the content and not the host) – and it’s starting to look very cool and very ‘you cant do that in DHTML’ish. Hopefully it’s smooth sailing from here.

I’d still like to learn how to do ActiveX/WPF on 64bit Sidebar (because it might be very useful for other scenarios) – but that adventure will be best left for another project.