Tag: C#

I came across a situation recently in which we needed an object in the client. Due to the cost of creating this object, we didn’t want to create it when loading up the window as it might not be needed (if the user didn’t click the appropriate button), we didn’t want to store it on the window’s main object graph, but equally, we wanted to keep hold of it once it had been created. This situation is not uncommon, where you have to create a class that is expensive (in database or bandwidth terms) to create. The obvious solution to this was to have a private variable for the instance of Expensive, and a second private bool variable to indicate if the Expensive object had been created. We could check the bool before accessing the Expensive variable. Even better, we could create a property that wrapped this up. Imagine our class is wittily…

When laying out controls on a window or user control, it is common to end up with wads of XAML that looks like this: Before you even start adding in the controls, you have quite a lot of XAML just for laying out the grid itself. Enter stage left, the GridHelper class (round of applause please). With the addition of the appropriate line to the namespace section of your window or control (depending where you save the GridHelper class): …you can reduce the XAML spaghetti above to the rather more succint: The row or column definitions are now reduced to a comma-delimited list of heights or widths. These can be absolute or star values, and can take an optional minimum value (specified after the colon). Grid splitters Grid splitters are a common feature in complex layouts, and the GridHelper class allows you to add them without writing extra XAML. All…

One of my first posts on this blog was about the problem of using anonymous types when you want to send the data outside of your current class. At the time, the only way I knew to solve this was to create a simple class that had the structure of the anonymous type, and create one of these instead of the anonymous type. I do this regularly, although I have taken to naming such classes CustomerOverview, OrderOverview, etc, instead of CustomerTmp as I did in that blog post, as they aren’t really temporary classes at all, they are slim, flattened overviews of the class.

This approach works well, but it can have its downsides. One, as mentioned in that post, is that it is easy to end up with a proliferation of classes, many of which may only be used in one location in the code. If the classes represent lightweight views of entities in the model (such as the two examples shown above), then I don’t worry about this, as it is clear what they represent, and it’s fairly certain that I’ll end up using them somewhere else at some point.

A common scenario is to have a button on a view that is bound to a command on the viewmodel. You can also have an ABCCommandCanExecute() method on the VM that tells the view whether or not the button can be clicked.

This is all fine until you want to ask the user to confirm the action that will be performed when they click the button. For example “Are you sure you want to reformat your hard disk, dial up all the people in your contact list and reformat their hard disks, and then destroy the world?” It’s kind of rude to do this without confirmation first.

The problem is that when you use WPF binding to bind the VM’s command method to the button’s Command property, you lose control over the execution process, and so can’t inject a message box into the flow.

Linq is great for grabbing entity objects. The code is simple, and you end up with known objects that you can use.

But, when you want to deal with anything slightly off the beaten track, it gets a bit harder. For example, if you have a Linq query that returns an anonymous type, you can easily manipulate it in the same code block.

Here I detail an early exploration into the world of anonymous types