Apr 6, 2011

Back at the start of 2009 I picked up an Alienware desktop (post and pictures here) and at the time it was perfect for my needs, and how I did love it so, but as theses stories go time passed and I found myself neglecting my desktop and spending more and more time with my other love – my laptop. It’s what I use for my day to day work needs and as fate would have it where I ended up running almost everything that I once used my desktop for including my PC gaming since it has a decent enough graphics card and I get to take it with me when I travel. The desktop has slowly been turning into nothing more than the place where I host my iTunes music collection. Sad, I know.

Now recently this machine has been randomly shutting down. Initially I thought it was related to a video card driver update that had just came through shortly after Win 7 SP1, but it was a little too random and a driver rollback didn’t fix anything so I cracked open the case to check the internals, and what do I find? That the heat sink and cooling fan are loose in their mountings! The plastic bracket used to hold the heat sink and CPU together had cracked and broken meaning that the CPU had only minimal contact with the heat sink. This would explain the random shutdowns.

So now I have a decision. Do I replace a few parts and get it running again or bid farewell to the desktop, and treat the laptop as the genuine desktop replacement it is? I’ve decided it’s time to say R.I.P. dear desktop and time to spend all my time with just the laptop. I’ll get an external HDD enclosure so I can still get my music and other files off the desktop drive, but that will be all.

So a question for you. Would you do the same if it was you, have you long said goodbye to your desktop and think I’ve been a luddite for hanging on to mine for so long, or would keep the big box and use simply upgrade the motherboard and CPU, etc? I’m curious.

P.S. If anyone wants to make an offer on a second hand Alienware desktop, needing a new CPU & motherboard with 4GB RAM and a decent graphics card, then let me know either via email or twitter.

Apr 5, 2011

I’m doing some work with a customer at the moment that has a large and complex application written in Progress, and they are wanting to do some work to add new features to it, but want to do so via Silverlight.

Now the way this application works from a UI perspective is that there is an application host shell with a menu and so forth, and when people request a screen it creates a new tab and hosts the appropriate screen in that tab. That screen could be a Progress GUI screen, a console screen or a web page, and now we need to add Silverlight screens to the mix as well.

Something like this:

Now for this to work we have to jump through a few hoops. We need Silverlight to be hosted in a web page, which means we’ll need to host a web browser control somewhere. We’ll also need to host that browser control in a WinForms user control since in Progress we can add a wrapper around the user control to make the whole thing callable via the Progress shell, as well as being able to receive events. When it’s put together it looks something like this:

What we’re also going to do is make sure we have just one Silverlight application containing all the Silverlight forms we want. We don’t want to create an application per form since that would likely turn into a huge maintenance and deployment problem and make development overly complex.

Now for all of this to work we will use the Silverlight to HTML bridge as well as the ability to have pages in the WebBrowser control talk to a .NET object via COM.

Wrap the WebBrowser Control

Let’s start by wrapping the web browser control. We could simply subclass it to do what we need, but if we do we won’t be able to get information back from the Silverlight UI the way we want, so we’ll instead create a custom user control and host the WebBrowser in that.

We’ll also create a few methods on the control to navigate to the page where the Silverlight application is hosted, and to request the particular Silverlight form we want.

Now this code isn’t quite so straightforward since we have some timing issues to deal with. If the Progress code simply calls “Navigate” and then “Open Form” I could be requesting information from the Silverlight application before either the web page or the Silverlight app has finished loading and if that happens then we’ll have errors thrown in our UI. This isn’t so good. We need to wait until things are ready before commencing.

Here’s the code we need. Note that a variable number of arguments for the Silverlight pages is catered for by passing an Object[] array as a parameter.

So a few things to note. First we hook the Silverlight onLoad event (highlighted) and use it to set a Boolean indicating wether the control has finished loading or not. Once the loading is complete the SilverlightLoaded function is processed where it toggles the flag and calls the navigateToFunction, if it’s been populated.

In the ShowForm function we check if the Silverlight control has loaded and if it has we call the NavigateTo method (we’ll get to that in a minute) and if not we populate the navigateToFunction which will be called once Silverlight has finished loading.

If you’re wondering the JavaScript call will mash the form name and the Object array for the parameters into a single arguments variable. We strip the form

And yes, for those wondering, this code can be made DRYer and cleaner. I left it like this to (hopefully) aid understanding.

The HTML to Silverlight Bridge

So now we have our WinForms control calling the JavaScript on our web page, but we now need to do a few things in Silverlight to receive that call. This is pretty simple:

The Navigation control here is an empty user control. There is nothing in it by default so we can load other controls up into it as the host. These other controls are the pages that we’re wanting our Progress code to be able to call.

Now to get the Silverlight bridge working we simply register the user control as a scriptable object and then mark the methods we want available to JavaScript with the [ScriptableMember] attribute. What you’ll note is that the Object[] array from JavaScript comes through to our Silverlight method as a ScriptObject. We need to convert it in Silverlight to an object collection before we can do things with it.

You’ll also notice that we’re using a collection of initialiser methods to avoid huge case or if statements that map from the string form name we pass through from the WinForms control to the actual form we’re wishing to display.

When we receive a request to load a form we check the collection for an initialiser, clear the current page and initialise the new one. Once we have a reference to it, we load the form up as a child of the navigation control which will automatically show it to our end users, and we’re done.

Raising Events Back In WinForms

So we can now display any form we want to from Progress. We then want to be able to click a button in Silverlight and have an event with some attached data raised back in WinForms for Progress to listen to. Let’s create an event indicating that the Silverlight app is asking the host app to open another form, such as a console or Progress GUI form.

And call this from a button click event. For ease of use by all forms this has been made static and resides in the NavigationControl class.

The HtmlPage.Window.GetProperty(“external”) call will retrieve from the web page hosting the Silverlight control any external reference objects on it. In our case that’s going to be the WinForms control. And we’re going to need to ensure that we create an AskHostToOpenForm method

Back in our WinForms control we need to now expose our control as a ComVisible component and tell the WebBroswer control that it is an ObjectForScripting. Doing so will automatically make all public methods on the control available for calling either from JavaScript or from Silverlight via the HTML Bridge as shown in the code snippet above.

We also need to add some code to our WinForms custom control to raise an event when the method is called (so that Progress can do something with it)

You’ll see that the number of parameters is fixed. I tried messing about with a variable number of arguments but when I did so the parameters were simply COM objects and there’s no way I was going to mess around with COM :-) I’m not that crazy!

Wrap Up

So there we have it, we can now have a Progress application (or any other WinForms app) that hosts a Silverlight form within a tab of the application and be able to get events back from that form when required.

The code for this is up on GitHub, so feel free to grab it and have a look at how it all fits together. If you’ve got any improvements to it that you want to suggest then please let me know. I’m always happy to get feedback!