Talk Nerdy To Me

Here’s a nasty bug that crept into one of my team’s projects recently. When will equivalent C# objects fail to compare as equal? The answer is “when operator== doesn’t work as expected.”

(more…)

All you geniuses and rocket scientists out there probably already know this, but I just stumbled on it, and I think it’s kind of cool. Did you know you can customize the adding and removing of C# event handlers? I didn’t.

I’m going to end this post with the question “Yes, but what’s it good for?” You folks with the Ph. D. in C#, feel free to scroll to the bottom and post your answers. For my fellow mortals out there, let me recap what I’m talking about.

(more…)

Ever get a phone call from an IT recruiter that leaves you scratching your head wondering “what was that all about?” You know – the recruiter who wants you to take a gig in a city you don’t want to move to, doing work you have no qualifications for, and for $15/hr less than your current rate? Yeah, they rankle me, too.

It’s not the recruiter’s fault.

Many IT staffing companies are utterly clueless about the extraordinary value their recruiters add to the company’s image in the eyes of job candidates. I’ve been a software professional since 1992 — C++, Java, and now C# — and I value the relationships I’ve formed with a handful of hot-shot recruiters in the Dallas area. Later, I’m going to hold up a lady named Shanna as an example of the sort of top-notch recruiter staffing companies should strive to attract and retain.

(more…)

Okay, so I blogged about how C# BindingList<T> serialization is broken and how to fix it. The problem centers around filling a BindingList subtype with items that implement INotifyPropertyChanged. This enables your list to fire ListChanged events indicating ItemChanged whenever a property of a list item changes. Unfortunately, serializing and deserializing the list causes the ItemChanged notification to stop firing unless you take steps to properly rebuild the list. This happens because C# event handlers aren’t serializable, and .NET fails to rewire the listeners.

A colleague of mine asked for a quick example to demonstrate the problem, so I whipped up this test case.

(more…)

When you move from one programming language to another, do you eventually find yourself thinking differently?

After eight years of slinging Java code, I converted over to C#. The C# language borrows (steals?) heavily from Java, but it also has added some features. Some of C#’s most valuable introductions to the language have now been adopted by Java. Things like attributes, generics, and auto-boxing – which first appeared in C# – have now been added to the JDK as of 1.5. It’s only a matter of time until Java adopts using-blocks and the yield keyword, too.

Despite this back-and-forth trading of features and enhancements, each language still maintains its distinct flavor. Some facets of each language – many of which are quite subtle – will probably never be adopted by the other simply because their introduction would create such a fundamental shift in language concepts it would invalidate a lot of prior work.

So, I was careful about my approach to C#. My Java work had been preceded by seven years of C++, and I remember what that transition was like. Although Java is strikingly similar to C++, the similarities are deceiving. Seemingly minor differences between the two languages created a sea change in how I thought, how I designed code, and how I tested applications.

(more…)

I previously blogged about how to use the C# INotifyPropertyChanged interface with BindingList<T> instances so that your lists properly fire the ListChanged event with a ListChangedType of ItemChanged.

In that post, I also alluded to the fact that BindingList<T> is flawed with regard to serialization of BindingList<T> subtypes. The problem has to do with the fact that BindingList<T> listens for PropertyChanged events on any of its list items that implement INotifyPropertyChanged. However, because event handlers are not serializable, those listener connections are lost during the serialization process for subtypes, and they don’t get rewired when the list is deserialized. It’s straightforward to do that, but the implementation is missing from the .NET SDK, so we have to write it ourselves.

(more…)

After reading Bil Simser’s discussion on DataTable vs. BindingList<T>, I’m convinced that BindingList<T> is the way to go for representing domain objects in C#. However, effective use of BindingList does require a certain amount of planning and forethought on the part of the developer. There are a number of things you can do to increase your chances of success with BindingList, but this post is about having your list items implement INotifyPropertyChanged in order to propagate change events through the BindingList itself.

(more…)

In software development, experience matters. A former boss of mine used to say “Good judgment comes from experience. Experience is the result of a lot of bad judgment.” Most of my sense of “the right way” to do things has been formed by first doing it in every conceivable wrong way.

In our rapidly changing field, there are seldom “textbook solutions” to problems. The textbooks are out of date shortly after they go to press! Thus, we defend our technical decisions – be it object modeling or database design – by pointing out the flaws in the alternatives. We become aware of these flaws by reflecting on past experiences with the same problem. A successful solution to the problem then produces a design pattern, and a proven design pattern applied to future projects allows us avoid prior mistakes.

That’s perfectly reasonable – mostly. Unfortunately, that can lead to a trap when we forget the original problem behind our so-called “best practice” solution.

(more…)