LUKE PUPLETT

While I’d followed Mr Toub and his gang while they were making the TPL, I’ve since slept and forgotten it all. So I can always consider a concurrent approach to my classes, I thought I’d make a very simple overview ‘cheat sheet’ and stick it to the wall.

Get it here.

This article discusses an issue I had when making a custom login box control, particularly the issue of getting the values in the username and password boxes to flow back down to the view-model. The issue might be my design, which could be fundamentally wrong, if only I knew of another way to do it.

The problem with Windows Presentation Foundation and its more promiscuous sister, Silverlight, is that its as good as it is bad. That is, its hard to deny its brilliance when you're carving out complex drawings and alpha gradients, adding subtleties to button animations and then there's the whole hardware accelerated 3D bit. But its bloody complicated because its mandate is to be everything to everyone and when so much is done for you all that stuff has to be massively multifaceted.

My LoginControl uses the parts and states model and the WPFToolkit to get at the VisualStateManager. I won't go into these things as they're documented enough and Karen Corby has a great MIX session video on it, too.

So I have a few parts, two TextBox controls and a Button. You can guess that these are username, password and the logon button.

Firstly, and I'll get this one over and done with quickly: I don't use the PasswordBox control. It does not support data binding because it takes a cautious approach and does things securely. Instead I apply a strikethrough formatting to a regular TextBox within its default style in generic.xaml.

You can see how this is done by reading my comments at the bottom of the MSDN article on the PasswordBox.

Welcome to my LoginControl

Cutting straight to the meat of the implementation, my control has the following properties:

• private TextBox UsernameTextBox // the property which stores the TextBox UI control part/element for the username
• private TextBox PasswordTextBox // the property which stores the TextBox UI control part/element for the password
• public string Username // the dependency property which stores the username that can be bound to from a view model
• public string Password // ditto but for the password

Because I can't bind my view model to a property of a the LoginControl's username TextBox and I don't want to expose the TextBox controls publicly, I use the following trick to hook up a binding between the TextBox.Text dependency property and LoginControl.Username (ditto for the password):

And once that's done there's nothing else to consider except that when adding my LoginControl to my XAML page, I need to hook up the binding to the appropriate properties in the view model. That's easy:

Username="{Binding Path=Username, Mode=TwoWay}" Password="{Binding Path=Password, Mode=TwoWay}"

No worries there.

In Practice it Fails

The problem occurs when the login button is clicked and the ICommand is executed. The RelayCommand on the view model kicks in and my Action runs but if I stop the debugger right there I see that my view model does not have up-to-date Username and Password values!

My theory is that the binding system has not done its magic in between my typing of text and clicking of button. And although in theory the LostFocus events upon which data binding updates rely should have been triggered, my daisy-chained setup is somehow ballsing things up. Actually, there is a LostFocus on the username TextBox which should update the LoginControl.Username property, it doesn't, but even if it had, what's the activator to get the value to then jump from the Username property to its source down in my view model? By the way, flows up from source seem to work fine.

Whatever, I don't know. My solution was to grab each of my bindings and manually hit the UpdateSource method from within the login button's click method:

Which brings me right back to the point I made earlier about not doing this the right way. I'm not sure any other way would flow the values in time anyway. But then there's always the question of how everyone else doesn't seem to have this problem...

...(even though you shouldn’t really).

The System.Windows.Application class, from which a standard WPF application class or entrypoint derives, offers up a SessionEnding event to which you can add a handler and use the SessionEndingCancelEventArgs.Cancel property to veto a system shutdown.

Before I go any further, I must stress that Microsoft advises that you don’t do this unless its for a very important reason such as a CD-ROM being burned (which would ruin the disc, if interrupted). Guidance on this and on the timings of forced closures etc. and even the wording you should use in your reasons (which I’ll come to later) can be found here: http://msdn.microsoft.com/en-us/library/ms700677(VS.85).aspx

A bit hit and miss

So my point here is that Microsoft don’t want you to do this in the first place and that the wording on the Microsoft.Win32 version of effectively the same event is that it is not guaranteed. See here.

The way I look at it is if you feel you’ve good enough reason to stop a shutdown and potentially annoy your users (who will inevitably blame Windows and Microsoft), then the system to do it should be guaranteed. In fact, the system used by unmanaged coders is.

In the unmanaged world, session ending notification comes via a message sent to the window. As we have already a system to listen for this, we will just use the WPF SessionEnding event.

As I’m using the Model-View-ViewModel (MVVM) pattern, my code will need some extra explanations but the important stuff is clear.

My ViewModel knows not of the App class of my application, so this code goes outside of where the actual action takes place, in the App_Startup handler.

My ViewModel base class has an OnShutdown virtual method that can be implemented by any derived view model, I do this because a) the view model often knows of the application state better than the App class does (which has no real logic) and b) view models are usually tied to windows and the Win32 API needs the window for this thing to work.

I abstract the reason enums to make it more flexible. The ref cancel argument is used because I don’t want to block a shutdown and then have WPF unblock it by returning cancel = false

A few interesting points in the code above. The first section is experimental/stupid: I don’t want to have a subsequent/concurrent caller dismissed and give the wrong message back to Windows so I sit on them for 4s. I should use a wait handle but that would require complex explaining – plus it works as is.

The second bit reacts to the shutdown type and starts doing some UI work. This being MVVM, a storyboard triggered by a property here could flag up the impending doom to the user and add to their awareness of the problem.

Then a call is made to TryBlockShutdown() which does the dirty deed before cancel is set appropriately and the call returns.

Where execution determines that the shutdown is fine, a message is sent to the UI and a call is made to TryUnblockShutdown() just in case it was left ‘switched on’ somewhere.

Note that you may be able to use these methods outside of a handler and not call them from within – block and unblock in response to Before/AfterCDBurn events for example, however I prefer to handle the session ending event so I can make sure to unblock the shutdown.

Microsoft urges you to pre-empt rather than react on-the-fly to the session ending event. Registering a reason to block a shutdown seems to live in memory until the window is torn down, so you must always call the unblock API.

Important: When the window closes, your block will be lost. My own application, which is a background app, actually hides the main window upon closure to make sure that this doesn’t happen.

The certain way

Behind the TryBlockShutdown method is a call to ShutdownBlockReasonCreate within user32.dll. Calling managed code requires the UnmanagedCode permission and so this is demanded and gracefully dealt with here.

So the main points to note here are the static extern bool methods, decorated with DllImportAttribute attributes and the MarshalAs attribute which appears before the string type definition for the reason argument.

Secondly and importantly, there is a call to this.Dispatcher which on my view model is the Dispatcher for the window so I can perform some work on the UI thread if I need to, which I do here.

Important: Calls to ShutdownBlockReasonXXX must be performed on the thread that owns/created the window to which the block applies and in WPF, this is the UI thread which is available via the Dispatcher.

Finally, there is TryGetWindowHandle which for me is defined in the base ViewModel class and skipping some of the logic for clarity, eventually ends up calling this code:

And that’s that. More information about the Model-View-ViewModel can found at these places:

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

http://jonas.follesoe.no/

And more on calling unmanaged code, here:

http://msdn.microsoft.com/en-us/library/aa288468(VS.71).aspx

A Technique for RIA UI Control Updates and MVVM

Its a fairly widely known fact of Windows programming that you can't update a UI control from the code executing in your painstakingly well-written worker object. There are a number of Framework constructs that are designed to help in these situations such as the Dispatcher as well as more low-level classes like the AsyncOperationManager which puts a slightly more friendly veneer over the SynchronisationContext. Whichever class you use, updating the UI usually involves writing dedicated methods in some place away from where the action is taking place.

I'm going to talk about using one of the simplest of the lot to re-unite things: BackgroundWorker.

You'll be able to go from writing asynchronous code straight to writing values to your view model with just a few lines in-between where the magic happens - all within the same method - so you can even pipe the variables declared and available within your concurrent method directly into the UI. Sounds to good to be true? Well I hope not because it seems to be working here.

About our Weapon of Choice

First up, a little bit of background about background, err worker. BackgroundWorker’s design centres on three events, DoWork, RunWorkerCompleted and ProgressChanged (I’d have called the first one RunWork but there you go).

Essentially, DoWork is triggered on a new thread-pool thread while the others are triggered on the UI thread.

Be careful though because ConsoleApplications seem not to jump back to Main Thread and I’m not totally sure if the design aim was to trigger on the UI thread specifically or just the same thread that the RunWorkerAsync method was called from.

I'd suggest reading more about it here (VB.NET examples).

The Delegate and its Wrapper

Jumping straight into code, the first thing needed is a vanilla delegate; parameterless and void. Next is a class which holds a delegate - we can't pass delegates in the way I'd like because they don't derive from Object so I’m sort of wrapping it up in a class which can be passed around.

Setting-up and Calling BackgroundWorker

To kick off the concurrent logic, we need to add some code somewhere in a method on the UI thread, either in a Window or some helper class. I’ve kept some extraneous code around to give it some context.

The VolatileState object is a hang-over from my test code so ignore it and pretend its says 'this' and points to a property on the Window1 class or something.

Interesting thing number 1: The DoWork method calls the StartSyncLoop method on the SyncManager passing in the BackgroundWorker that’s hosting it and a ViewModel which in turn has a constructor which points to the page we’re on. If we’re relying on data binding to do everything then we don’t need to pass a reference to our window, we just need a ViewModel instance with all the right bindings. My example uses an explicit UI control manipulation because its more obvious.

Interesting thing number 2: The ProgressChanged event handler method casts the UserState property of the event args back to a UIWorkWrapper and then invokes the delegate its wrapping!

The Synchroniser Thingy Class

If you haven't guessed by now, to get into the spirit of asynchronous activity I’m using a hypothetical example of a synchronisation loop which might keep an application in synch with a web service or something. The premise being that this method is called by the DoWork event handler code and so will begin its duties on another thread (note that thread-pool threads are actually supposed to be used for short bursts of work and not long-running background synch maintenance type tasks... but I won’t tell anyone if you won’t).

And that’s it. The asynchronously running loop can modify the ViewModel directly via an anonymous method delegate which will be run on the UI thread - note how the variables flow right through. The Status property could be data-bound and the PostStatusMessage could do something like this (this.Control having been set in the constructor to the Window1 instance):

Thanks and good day to you.

"Stay away from the nice doggy, children."

While reading the excellent (if somewhat late) Concurrent Programming on Windows: Architecture, Principles, and Patterns (Microsoft .Net Development) I began trying to recall the countless times that I have taken advantage of the framework's APM methods you get for free when you new up a delegate. Here's the noteworthy passage from page 418:

All delegate types, by convention, offer a BeginInvoke and EndInvoke method alongside the ordinary synchronous method. While this is a nice programming model feature, you should stay away from them wherever possible. The implementation uses remoting infrastructure that imposes a sizeable overhead...

Joe's choice of the word nice being a colloquial English word meaning not nice, shit, a poor effort. The scarcity of information from reliable sources and the arguments and proliferation of inaccuracies in the area of concurrency in .NET had me guessing that Joe's book would contain some nasty surprises which is why I'm somewhat peaved that such an important reference has only just come available, eight years after the Framework was released - and two years into my own person journey of asynchronous discovery! --grrrr.