I ran across this good post today while searching on using objects represented as a MonoState or Singleton pattern in WPF databinding:

Monostate vs. Singleton : Adventures in WPF Databinding [The .NET Addict's Blog]

The gist of it is that objects represented as a MonoState may not work property with property update notifications.  This kind of makes sense as the UI will be bound not to the actual object, but the wrapper around the internal singleton.  Hence, property change notifications on the singleton may not make it up to the UI since they bubble up but there really isn't anywhere to go as they are not actually bound to a UI control.

So, the summary is be careful if you do this.

One of the things that I typically like to do when writing an application is to code one or more "Model" objects.  A model object is an object that represents a representation of domain objects and that provide a unified interface to those objects similar to what is provided by using the 'Facade" pattern.

I typically create the model object(s) in the constructor of the application, and then allow access to them through properties in the application object.  Since the application object is a singleton (yes, another pattern) any other object (specificailly those that are WPF framework objects) can access this singleton and also the domain objects of the application. 

The advantage of this is that it provides the ability to have a centralized place to access the objects instead of having to either spread them out all over the application, or to constantly have to serialize / deserialize them from persistent medium.

In an application that I am currently building I am doing this, and I have a user control (actually I have a few) that during initialization need to access the model object during their initialization to pre-populate their data (such as items in a listbox).  Matter of fact, this is actual code that I had that was doing just that:



This code works great at runtime, but it has issues at design time.  At design time, when editing a control, the designer actually instantiates an instance of the control to provide the designer with a visual representation and access to the properties of the control in the property editor.  However, at this time, since it is design and not run time, the App.Current object is NULL!  I guess that this makes sense, but it caused an exception to be thrown that renders an error message in the designer :-(.

The initial reaction I had to this when I figured it out was to change the code to be the following, which solves the problem quite handily:

However, this works well if you are working within your solution within VS.NET.  As this model has other issues, as described in this article.  The If statement will solve the problem within your own solution, but if the control is being used by another application at design time such as Blend, then the Application.Current object may not be your application object but Blends application object, and hence the TorrentModel property many not be found.

Second, although this code works fine within your own solution, I hate that I am now putting special code into the app to test for design time operation.  This then gets back to how can I remove this code and do this just in XAML?

Well, that will be the topic of a future post.

Here's a little XAML trick for when you are trying to dynamically size a display element based upon the size of another element.  This is useful when you need to resize a parent element based upon the size of it's content, but where the parent element may also be incorrectly sized due to its being a part of another control such as a grid.

For example, I am building a small control that will be used as a header on a window that consists of three components, a set of window control buttons (min, max, close) that are left justified, a menu that is right justified, and a caption (some text) that spans the entire space between the two other elements.

The window controls are a fixed size, but the menu can be a variable size depending upon the number of items that are in the menu which may not be know until run-time.

A naive attempt (like I did at first being used to tables in HTML) at declaring this in XAML would use a grid declared like this:


The problem with this as that the layout engine will split the width of columns 1 and 2 to be even in width, which renders something that looks like this:



Not exactly what I expected, as I was hoping that the layout engine would only make the column for the menu as wide as the menu, and splitting the second column with the width therefore made the caption too small and only filling about half of the area I wanted.

There are potentially a number of ways to solve this (including code behind to handle ArrangeOverride and MeasureOverride events), but the simplest way is to bind the width of the thrid column to the ActualWidth property of the menu control.  This changes the column definitions in the grid to the following:


Which makes the window look like this:



Which is just what I wanted!

How/why this works is due to the hierarchical and multi-pass nature of the WPF engine, and the integration to data binding.  Basically, the control will lay itself out and the grid will define the two columns to be of equal width.  After that, but prior to rendering, the data binding engine will read the value of the ActualWidth property of the menu control (which has been decided already through the just completed layout process) and assign it to the Width property of the right-most column, which will also cause the middle column to resize to take up that space.

And all of that with just a few lines of markup!