Peter Ritchie's MVP Blog

Trials and Tribulations of DataGridView, Column Selections, and Sorting

I had to implement some custom sorting in a DataGridView recently.  Essentially, the stakeholders wanted full column selection (like Excel) while still having the ability to sort the data based on a particular column.

This particular DataGridView is data-bound.  DataGridView offers the Sort(DataGridViewColumn, ListSortDirection) method to perform this.  Nice and easy I thought: I’ll set the SelectionMode to DataGridViewSelectionMode.ColumnHeaderSelect and simply call Sort with the selected column.

Well, much to my chagrin this had the side effect of making that column look selected all the time.  No matter where else I clicked, that recently sorted column looked selected (SelectedColumns had a count of zero).  And to add insult to injury, when I control-clicked that column (thinking it was selected) to unselected it, it caused a NullReferenceException deep in the framework.

Suffice it to say, this makes it very difficult to sort by columns in DataGridView without using the built-in sort-column-when-header-is-clicked mode.

What I’m now attempting to do is to unselect the column before sorting it.  This, in itself, is not trivial either; there’s no public method to select or deselect a column in the DataGridView.  I’ve had to create a new DataGridView derivative and call the protected method SetSelectedColumnCore.  A few hoops…

I’ve logged a couple of issues on Microsoft Connect about these problems.  The first is about ctrl-clicking the column and getting an exception:  https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363623 The second is about the visual state of the column remaining “selected”: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363623 Attached to this post you will find the project referenced by the two Connect issues.

[Update: I've currently only tried this with a .NET 2.0 project in Visual Studio 2008 SP1; if you find this problem occurs in Visual 2008 RTM, please comment.]

[Update: I overlooked the DataGridViewColumn.Select property, so there's no need to derive from DataGridView]

Drag and drop of control selections onto forms designer toolbox

A while back I blogged about the ability we have in Visual Studio to select text in a text editor and drag it onto the toolbox.  Once on the toolbox you could drag those items back into the text editor to effectively “paste” frequently needed snippets of code into other text files.

Imagine my surprise when we didn’t have this ability in the forms designer.  When writing code, it’s a bit specious to want to have multiple copies of hard-coded snippets of code (DRY should come to mind).  But, for forms, the only alternative is to create user controls to contain commonly-used control groups.  User controls is very heavy weight and basically becomes unusable when talking about simple groups of buttons.  For example, “OK” and “Cancel” buttons.

So, as a result, I’ve logged a suggestion on Microsoft Connect suggesting this ability be added to Visual Studio.

If you want to see the potential of a feature like this, see http://machine.nukeation.com/preview.html

Location of unit tests.

I had a short  conversation at Alt.Net Canada about the location of unit tests.  I personally tend towards a distinct unit test project.  But, I deal with mostly commercial, off-the-shelf (COTS) projects where I simply can't ship code like that.  I also don't want to wire-off the unit test via #if because I would then be shipping something different than that which was tested.

From an enterprise application point of view, this is different.  I would have no problem including the unit tests within their respective project as production code

The winds of change are blowing

The essence of ALT.NET, or at least the essence that people made use of, was that it was a venue for improving one's skills.  There has always been an undercurrent of other agendas there; but they never really took root.

The problem with the ALT.NET moniker was it isolates it from most of the industry--it was an island of .NET practitioners.  This basically flicked its thumb at the other communities--other communities that propagated some of the guidance that ALT.NET was trying to proliferate.

In the very spirit of continuous improvement it seems that ALT.NET is attempting to evolve and the ALT.NET conferences may continue (at least for a period of time, until the next kaikaku) as Kaizen conference.

Kaizen is a much more appropriate name for what people use and get out of the ALT.NET conferences.  I just hope this change doesn't cause division, distrust and dissent (for lack of a better word).

I've said from the beginning that "ALT.NET" had some flaws as a name.  I hope Kaizen will continue to give the same people the ability to improve, while embracing more.

Extra Features: One of the Lean 7 Wastes of Software

Derik Whittaker recently blogged about how writing unused code is one of the Lean 7 Wastes of Software.  Mary Poppendieck calls this "Extra Features" and has a one-to-one association to overproduction in manufacturing. 

In Manufacturing it has different caveats: if you overproduce something you have to have somewhere to store it until its sold.  What do you do when you don't have the space to store it?  If you have the space, it's not too much of an issue; you just tuck it away; but you still need people to move it, manage the space, manage the responsibilities around moving/storage, etc. etc.

With Lean Software, there is still technically a storage issue (VCS, disk space, etc.).  The real issue with extra features is that no one is using them. In the best case this means you're consuming expensive resources that aren't directly increasing revenue.  Worst case you're also impacting the usability (and thus the sell-ability) of the software.  If the extra features are something that the vendor hopes to be used in the future; then you've increased the time between implementation and fixing bugs.  Unit testing aside, when customers log bugs against the software regarding something implement 6 months ago, you've increased the cost of fixing the bug exponentially as time goes on.  This is the philosophy behind TDD, that unit tests find bugs as soon as possible (~build time, depending you your setup).

From an Agile standpoint, extra features mean you're giving the user something they didn't want.  This means you're not listening to your customer and don't have a relationship built on communication.  In Agile, it's a tenet to build prototype code based ideas you've inferred from communication with the customer.  This isn't extra features, this is the feedback process.  It's fine to propose a feature to the user in the form of a prototype; but if they don't want it, it doesn't go into the release.

Extra features is technical debt that you'll have to pay for eventually.

Law of Reversibility of Attributes

I've come up with a simple law called Law of Reversability of Attributes.  It’s based on the physics law of a similar name.  Basically what the law means is that the inverse of a transformation should result in a return to the original state.

The Law of Reversibility of Attributes is defined as:

For a given state of an object; when a attribute’s value is changed, the inverse of that value, when applied to that attribute, will result in the object returning to its original state.

I say “attribute” rather than “property” to encompass methods that imply setting of attributes.  So, for example

            myObject.BooleanValue = !myObject.BooleanValue;

            myObject.BooleanValue = !myObject.BooleanValue;

and

            myObject.SetBooleanValue(!myObject.GetBooleanValue());

            myObject.SetBooleanValue(!myObject.BooleanValue());

means myObject will be in the same state after the second line of code than it was before the first line of code.

[UPDATE: interestingly, after I wrote this post--which was delay-published--Bill Wagner wrote a great article on a very similar topic in Visual Studio Magazine]

DataGridViewColumn.Frozen

DataGridViewColumn.Frozen is documented as "When a column is frozen, all the columns to its left (or to its right in right-to-left languages) are frozen as well."

Which is nice until you think of the consequences.  The consequences being that freezing a column and all columns to the left is performed with a single assignment of true to the Frozen property of that column; but to unfreeze is not the opposite (a assignment of false to the Frozen property of that column).  No, you must unfreeze each of those columns to the left.  This can be done by manually unfreezing each column, or by unfreezing column 0.

This means that column.Frozen = false is not the opposite of column.Frozen = true—resulting in unbalanced reversible side-effects.

Neither of the techniques to “unfreeze” the column that was frozen is intuitive; but unfortunately this interface is not "intention revealing".  You’re not just setting the Frozen property of a column, you’re setting the frozen property of that column and all the columns to the left.

Greg Young recently commented (I don’t remember where) about writing classes without any properties.  This approach would have helped here.  What Greg is alluding to is to recognize behaviour rather than shape.  Freezing the current column and all columns to the left is a behaviour, not an attribute; and it should be modeled as a method rather than a property.

At any rate, if you have a DataGridView on your form, you may be interested in using these methods instead:

        private void FreezeAtColumn(int value)

        {

            dataGridView.Columns[value].Frozen = true;

        }

        private void UnfreezeColumns()

        {

            dataGridView.Columns[0].Frozen = false;

        }

Microsoft Knowledge Base Themes

Does the look of Microsoft Knowledge Base articles bore you?  Well, you can spruce them up with a Zune or X-Box theme.

For example, http://support.microsoft.com/kb/312906, looks like this:

By simply adding ?sd=xbox or ?sd=zune to the end of the URL, you can change it to look like this

and this

… respectively.