Tag: C#

As part of some overall auditing in one of my projects, we recently added a LastUpdatedByUserID column to all of the major tables. As the name implies, this column stores the ID of the user who last updated the row. In order to keep an audit trail of the changes, for each table in the database, we have a corresponding TableName_Audit table that is updated (by triggers on the main table) every time the main table is modified.

I noticed that for one of the tables that had had the LastUpdatedByUserID column added, the script to regenerate the audit table hadn’t been run, so the audit table was missing the LastUpdatedByUserID column. This would entirely nullify the point of the column.

This led me to wonder if there were any other tables in the same state. rather than check this manually, I decided to write a script to do it, as this would be useful for future tables. Being a Linq type of person (I rarely write SQL any more), I decided to see if I could do this in LinqPad.

It took a bit of fiddling, but the end result was what I wanted, and paved the way for future queries.

A while back I blogged about a situation where thinking out of the box helped me write some code more quickly. In a nutshell, I needed to extract an exchange rate from an XML feed, and found that by using F# to do it, then translating the code back to C#, it was much easier than trying to write the code in C# in the first place.

I thought it might be interesting to revisit this in both languages, and compare the two experiences. I found this to be a significantly better sales pitch for F# than anything else I’ve seen.

If you’ve ever had to write or read a regular expression, you won’t need any convincing that a tool to make this easier would be useful!

If you aren’t familiar with regexs (as they are colloquially known) then it’s worth getting to know, as they can be amazingly useful at times. Sadly, they can also be amazingly difficult to write, and impossible to read afterwards!

Here are a few tips for taking away the pain.

Does this sound familiar…

User: Your app just crashed
You: What happened?
User: It crashed
You: (sigh) What were you doing at the time?
User: Using the app
You: (sigh) What specifically were you doing?
User: I was clicking in that box
You: Which box?
User: You know, the one on the window you get when you click the other button
…and so it goes on

Read how we managed to get useful information about errors without having to suffer speaking to the users!

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)

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…