Not a common requirement, but as it can happen, and was an interesting one to solve, I thought it worth documenting. The scenario is this: For a medical system, there are a number of treatment sites (ie bits of the human body) that must be checked. For each treatment site, there will be a number of check types that need to be done. We needed to display this information in a grid like this (this is a prototype, so only shows True and False, rather than having checkboxes that can be altered)… The treatment sites are listed in the first column, and are pulled from a database table. The interesting bit here is that the 2nd column onwards are not fixed, these are also pulled from a database table, making the grid dynamic. We don’t know in advance what columns will be needed (other than the first one of course).…
A hopefully enlightening story.
I had the need to get the latitude and longitude for UK postcodes. Knowing that another developer had recently done a lot of work doing similar things using the Google Maps API, I had a look at the code she had written. Following the Google guidelines, she had ended up adding wads of C# classes, defining the various data types that the API returns, as well as a lot of helper methods to parse the data. I had that horrible sinking feeling you get when you can see a small design requirement blow up out of all proportion.
Whilst contemplating the problem, I had an epiphany, and realised that I could solve the problem in a much simpler way, albeit with some initial effort. I thought the technique might be useful to others, but more significantly, thought that the idea of thinking outside of the box may be of interest.
OK, so hands up who knows the difference? Hmm, just as I thought, not many. Don’t worry about it, nor did I until just now! Rather than rambling on (as usual), I’ll just point you at a StackOverflow question where this was answered as clearly as this is likely to be answered anywhere! http://stackoverflow.com/questions/2876616/returning-ienumerablet-vs-iqueryablet By the way, if you just query your EF context and don’t explicitly convert your results, you’ll end up with an IQueryable<T>. If you use .AsEnumerable(), you’ll end up with an IEnumerable<T> (surprisingly enough).
A few years ago, I blogged about how to implement an “Are you sure” pop-up in MVVM. Well, I’ve grown up (a bit) since then, and realised that the code there wasn’t testable. I therefore take great pleasure in presenting for your delight, a testable “Are you sure” pop-up in MVVM. Aren’t I kind 🙂
Being good boys and girls, we want to write testable code, so if by some miracle we ever get around to writing unit tests, we can run them safe in the knowledge that they stand a fetid dingo’s kidney’s chance of working! One of the main issue involved here is ensuring we keep all view-related code out of the view model.
This post explains how to do it (with some pointless pictures)
As I briefly mentioned in my rant aboutÂ the F# fanboy lies, I have been usingÂ Project EulerÂ to help me learn F#. I have got as far as problem 8, which was to find the largest product in a series of digits.
Apart from the fact that this was an interesting problem, I learnt a very important lesson from this one, and thought it worth sharing.
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.
I had the need today to add my own property to a WPF user control, and have that property available in the Properties panel of the Visual Studio designer, so the property could be set at design-time. The purpose of this was that my user control had a toolbar, and I had come across the need to use the control, but not show the toolbar. Simple eh? Well, not quite!
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.