Welcome to Imar.Spaanjaars.Com

Ever since I wrote the initial version of my ContentRating control back in 2006, I received a massive amount of feedback, both as comments below the article and as private e-mails. Not surprisingly, if you consider the article has been read over 19,000 times and has been rated 444 times (at the time of writing).

Besides getting a lot of "thank you's" from people who liked the control, I also got a lot of requests for a real-world example of a test site using the control. The test site that shipped with the control used fake data stored in ViewState to simulate a real backing store which obviously didn't cut it for a lot of people.

Also, a reader called vgt pointed out a bug in the control where an existing cookie would be overwritten by a new one one, effectively allowing you to vote for the previous item again.

Finally, I had a few requests of my own: I didn't like the default data source of 5 integers if you didn't supply a data source yourself. I also didn't like it that the control didn't raise an exception when you tried to data bind it without a valid data source.

So, enough reasons to fire up Visual Studio and get my hands dirty on some control fixing.

Some time ago I was showing a colleague how to enhance an object's Design Time capabilities (or actually Debug Time) by adding a DebuggerDisplayAttribute. I blogged about this attribute earlier, so I won't go into it again now. But what I do want to talk about is the way the attribute gets its data.

It's not uncommon that you have a method that accepts an object that implements the IDataRecord or IDataReader interface. It's also not uncommon that you cannot (fully) control the query that drives the IDataRecord. It could be the result of a SELECT * operation (bad idea) or it could be the results of a Stored Procedure for example. Especially in the latter case, it can be useful if you can check whether the IDataRecord contains a specific field. For example, you may want to check if the IDataRecord has a field called LastModified before you try to read and store this field in a local DateTime variable.

Unfortunately, the IDataRecord and IDataReader do not implement this behavior directly. However, it's easy to add with a simple extension method.

Sometime ago I was working on a Web Application Project in Visual Studio 2008. The web site I was working on couldn't run against the built-in web development server, so I ran the application against IIS 7 on my Windows Vista machine (IMO, that's probably the best reason to upgrade to Windows Vista if you are a web developer: multiple web sites in IIS 7).

Life was good until I started debugging...

I just uploaded a ZIP file with four MyGeneration templates to generate C# and SQL code that matches the model in my articles about N-Layer design.

A colleague (from Design IT) and I were discussing a simple way to check two instances of an object. We wanted to know if all the public properties on one instance were holding the same values as the one on the other instance. We wanted to use this knowledge in a few unit tests to simply check all public fields on an instance in one fell swoop.

Since we didn't want this exact behavior at run-time we couldn't override Equals and check all object's properties, so we had to look for a different solution.