I’ve often wondered if software “breaks down”, as if in some chemical process, if left untouched. I remember clearly an application I wrote for a client back in the early 90s, using Visual Basic (the original). We got it deployed, and I didn’t hear from the client for a while. Then, all of a sudden, he’d call with a complaint like “it won’t print” or “invoices don’t appear on the main menu anymore.” What the heck? Nothing changed on the computer. This was in the days before the Internet and the constant barrage of online updates. The only logical explanation? Software leprosy. Bits jumping off the hard drive. Disintegration of the fabric of time and space. I don’t know, but there was no reason for that application to fall apart on its own.
Last month, I left for a week-long business trip. I had written a complete “Exploring Visual Studio 2008” course using my desktop computer, and all worked fine. I turned it off as I left. I unplugged it, so it didn’t suck any extra electrons from the wall. (You do know that hardware, even when turned off, can pull electricity, right? Phone chargers, even when not charging, waste electrons. Same for TVs, stereos, and more. So I just pull the plug on the power strip when I leave home for a week.)
On return from the snowy/cold north, having recorded many hours of video training, I flipped the switch, turned on the computer again, and sat down to work. Again, I respond, “What the heck?” The LINQ to SQL classes designer in Visual Studio has simply stopped working. Now, remember, the computer was off and unplugged while I was gone, and it worked fine as I left on the trip. How did this important feature (at least, to me) in Visual Studio 2008 break off and melt, like some huge part of the Antarctic because of global climate change? Was it magnetic rays? Solar flares? I can’t tell you, but I have yet (three weeks later) worked out how to get this feature working again. I have uninstalled/reinstalled several times but haven’t yet taken the “repaving” path.
Here’s another example: Recently, I tried to do something I swear I’ve done a million times-that is, bind contents of an array to a DataGridView control. For example, imagine this code, given a DataGridView control named DataGridView1 on a Windows form (I’ll let C# folks perform the conversion in their heads, this time):
Dim states() As String = _
{"California", "Texas", _
"Washington", "Arizona", _
"New York", "Florida"}
DataGridView1.DataSource = states
I assumed that I would see the list of states in the grid. Try it. What you see, instead, is a list of the lengths of each state’s name. (For example, this array displays 10, 5, 10, 7. 8. 7; one item per row in the grid).
My immediate assumption was that Visual Studio 2008 had somehow broken data binding, because I was sure this had worked in the past. I went back to Visual Studio 2005, and guess what? It works exactly the same way there. In this case, then, it wasn’t bits falling out of the software that caused the trouble; it was bits falling out of my brain, which had clearly never really handled this particular task, obviously. It looks like the DataGridView control, when bound to an array, attempts to find a simple property of the elements of the data source to display within the grid. Because strings only really supply one simple property, Length, that’s what appears in the grid.
To be honest, this is really what I tried recently:
Dim states() As String = _
{"California", "Texas", _
"Washington", "Arizona", _
"New York", "Florida"}
Dim query = _
From state In states _
Order By state _
Select state
DataGridView1.DataSource = states
Because this code, too, displayed a list of lengths, I thought perhaps it was the LINQ query that broke the databinding. It was only then that I tried binding directly to the array, and noticed that it still didn’t work, did it become clear that this is the intended behavior, and that it has always worked this way.
So perhaps bits were jumping out of my brain, and things were falling apart. But there has to be a solution to this issue, right?
I tried a lot of things, mostly a waste of time. Luckily, today, the answer showed up on a mailing list to which I subscribe, and the answer is so simple (as long as you’re willing to use new features): An anonymous type. The following code (thanks to Ken Tucker), does the job:
Dim states() As String = _
{"California", "Texas", _
"Washington", "Arizona", _
"New York", "Florida"}
Dim query = _
From state In states _
Select New With {.Name = state}
DataGridView1.DataSource = _
query.ToList()
In C#, the same code looks like this:
string[] states =
{ "California", "Texas",
"Washington", "Arizona",
"New York", "Florida" };
var query =
from state in states
select new { Name = state };
dataGridView1.DataSource =
query.ToList();
In both languages, the code creates an anonymous type (that is, a type without a specific name) and fills the results of the query with a list of the new type. Because the type supplies a Name property containing the text, the DataGridView can perform its magic and display the list correctly. You do need to call the ToList method of the Enumerable result, however, in order to see the list in the grid.
There’s a name for this sort of behavior: Entropy. The older I get, the more I feel it: the natural tendency for things to become less organized, to simply “fall apart.” Whether it’s gravity, old age, sunspots, or magnetic fields that causes it, it’s inevitable. In this case, we’ll blame old age. In the case of my 1990’s client, it had to be sunspots. That’s the only explanation I can come up with. Or maybe I just forgot what really happened?
