WPF: Replicating MDI Application Behaviour

I decided to use Prism, aka Microsoft Composite Application Guidance For WPF and Silverlight.

This is very much like using a supersonic jet fighter to pop down to the local shops but its effective, not very hard and does not require you to write reams of fragile custom code. You just need to spend a bit of time getting used to Prism. Now that’s not a trivial task, but you should have covered the fundamental concepts within a working week, assuming you have some prior knowledge of Dependency Injection.

The huge advantage to you is that Prism is written by people who are much better programmers than you or I are, so the code is robust, whereas writing a custom MDI Window Manager is out of the league of most Intermediate-level developers (most of us).

Very simply, Prism allows the development of Modular Applications in which the User Interface of an application is decomposed into loosely-coupled Modules, each of which occupies a specific area on the screen, known as a Region.

No window (known in Prism as a View) can move outside the Region in which it is contained. This replicates the MDI-like behaviour you’re looking for.

Prism is also a library of Best Practices – it’s produced by the Microsoft Patterns and Practices team – so you get heaps of built-ins for free. And there’s a helpful forum where others using Prism are happy to help us newbies.

You can also have multiple windows (views) open simultaneously if you want, but this will render as a tabbed interface which is not exactly the same as MDI.

I embarked upon this approach and have been successful in producing a MDI-like app. It wasn’t too hard and I learnt heaps along the way. Go for it.

Over-Complexifying WPF Applications using Prism

For those getting started in WPF I recommend the WPF Boot Camp 2008 videos. Make sure you clink on the extended list of links.

An unexpected highlight was Glenn Block of Microsoft Patterns and Practices talking about Prism, the Composite Application Block for WPF. While valiantly attempting to explain Prism to a beginner audience in WPF without assuming prior knowledge of Dependency Injection, Glenn tells us:

There are things we can do to avoid over-complexifying an application beyond its natural complexity

I had trouble understanding this so I used Babelfish to Refactor it into Portuguese, from there into French, from there into German, from there into Greek and than back into English:

It exists things that we can make avoid a sobre-complexifying application apart from their natural complexity

That was a little better, but for added clarity I performed a second-phase refactoring, repeating the previous steps:

It exists the things that a application sobre-complexifying omitted their natural complexity you avoid this they can it can

If you have any further questions, please ping the Microsoft Patterns and Practices Team.

WPF MVVM in VB.NET: Delegating Event Subscriptions for RoutedCommand (or any ICommand) in the ViewModel

Just started a new project in WPF. It’s my first WPF project and the firm’s first WPF project. Should be lots to blog about.

Stick One In His Eye

We are using MVVM because the WPF Pantheon (e.g. John Grossman, Josh Smith and Jason Dolinger) are in agreement that this pattern is eminently suited to WPF. So, yeah, we’re taking a bit of a Voodoo Architecture approach.

I am writing a Proof Of Concept using MVVM and found an absolutely brilliant video by Jason Dolinger here which shows a comprehensive refactoring example in MVVM while lucidly explaining the pattern. I was following the vid while coding my Proof Of Concept but got well and truly stuck on the part where Jason delegates (that’s del-e-GATEs as a verb) event subscriptions for the RoutedCommand in the ViewModel.

The Google To End All Googles

The reason I got stuck was that the vid is in C# whereas I am using VB.NET, which is not a problem in itself, but Jason was using C# Event Accessors to delegate the Event subscription. I had never heard of Event Accessors, Jason did not say what they were and VB.NET does not have them (at least not by that name).

I commenced a Google and soon saw that all the MSDN WPF examples are in C# only and not in VB.NET. I was looking for something I didn’t know the name of to do something I didn’t understand in a language which did not have the construct I needed. I was just about to wave a Dead Chicken at the monitor when, in the end Google did cough up an answer…in French. Impossible n’est pas français.

Here’s what had me stuck. What I needed was the VB.NET translation for this code

public event EventHandler CanExecuteChanged
{
add { CommandManager.RequerySuggested += value; }
remove { CommandManager.RequerySuggested -= value; }
}

First I had to figure out what the heck it was doing. Jason just said ‘now we have to wire the ICommand into the WPF Commanding system’ which left me very little the wiser. Well, ladies and gentlemen what you are witnessing above is the use of an Event Accessor to delegate (That’s del-e-GATE as a verb, not DEL-e-gate as a noun) event subscriptions.

In more detail, the ‘add’ Event Accessor is fired when an Event Subscription to CanExecuteChanged occurs. Value contains the Delegate i.e. Event Handler which is subscribing to the Event. Hence, the Event Handler denoted by value is being added to the Event Handler List for the CommandManager RequerySuggested event. This has the effect of wiring the WPF ICommand object that has that event subscription into the WPF Commanding infrastructure, thus allowing that ICommand to take effect.

VB.NET does not have Event Accessors but it does have a direct equivalent, namely Custom Events. Here’s the equivalent VB.NET code:


Public Custom Event CanExecuteChanged As EventHandler Implements System.Windows.Input.ICommand.CanExecuteChanged
AddHandler(ByVal value As EventHandler)
'This is the AddHandler block
AddHandler CommandManager.RequerySuggested, value
End AddHandler

RemoveHandler(ByVal value As EventHandler)
'This is the RemoveHandler block
RemoveHandler CommandManager.RequerySuggested, value
End RemoveHandler
'
RaiseEvent(ByVal sender As Object, ByVal e As System.EventArgs)
'This is the RaiseEvent block
CommandManager.InvalidateRequerySuggested()
End RaiseEvent
End Event

You can see its the same thing as a set of C# Event Accessors.

For the above code I am sobbing in helpless gratitude to binoo, moderateur of the WPF Forum at Devellopez.Com who posted the above code in this thread, entitled Modèle MVVM – Implémentation ICommand

What Are Custom Events ?

Mesdames and messuirs, you may read about Custom Events here. They enable custom handling of AddHandler, RemoveHandler and RaiseEvent calls for any event.

The above code, for example says that when AddHandler is called for a CanExecuteChanged event that the event handler for that event should be added to the RequerySuggested event of the CommandManager. The inverse happens for RemoveHandler and CommandManager.InvalidateRequerySuggested() is called when a RaiseEvent is done on a CanExecuteChanged event.

Further Reading

I will assume that anyone interested in this post knows about MVVM in WPF and why I would be wanting to wire up ICommand objects in the ViewModel, but for those who have heroically read this far without that pre-requisite knowledge, just click on the MVVM link at the start of the article and the one about the MVVM refactoring video.

And to binoo, now my favourite moderateur in the world, may your hovercraft be ever full of eels and your Brie only Triple Cream.