The Problem

You may have noticed that .NET won’t let you change the Text value of a ComboBox during the SelectedIndexChanged event. This can be quite frustrating and difficult to work-around if you have want to update the ComboBox text during a when the user makes a selection. For example, you might want to back out of a bad user selection or bind each selection item with different formatting when selected. Let’s clear up a couple things that will help us understand why .NET prevents us from doing what seems like a reasonable default functionality, and then we’ll show one way to workaround this limitation.

Understanding the System.Windows.Forms.ComboBox

When you select an item from a combo box, the SelectedIndex property of the ComboBox changes to the index location of the item you selected. The ComboBox Text property is automatically updated to the display value of the item at the specified index. This is the only update to the ComboBox Text that is allowed by default. To understand this, let’s look at another out-of-the-box ComboBox behavior.

If you have a ComboBox populated with the following items:

1. Red
2. Blue
3. Green

Let’s say the current SelectedIndex value is -1 and the current Text value is Select a color...

If in our code we change the value of the Text to blue:

ComboBox1.Text = "Blue"

Then .NET will automatically recognize that this matches an item in our collection and change the SelectedIndex value to 2, thereby also firing the SelectedIndexChanged event. The reason .NET won’t let you change the Text property during a SelectedIndexChanged event is because they are worried about creating an endless loop by firing another SlectedIndexChanged event.

The Solution

We can resolve this relatively easily by invoking a delegate during the selection changed event that will eventually change the text property. We’ll load a generic WinForms window by adding two items to a ComboBox, one of which we want to reset the form when selected. This item represents a selection that may or may not be invalid, but is expensive to figure out, so we don’t want to necessarily evaluate it early and remove it from the list before the user has a chance to select it.

We’ll start by declaring a Delegate Sub within our class. The only important thing about a Delegate is the method signature that you are passing in. Since we want to call the ResetComboBox method which contains on parameters, our Delegate will not contain any arguments as well.

On the SelectedIndexChanged event, we’ll call BeginInvoke and specify that when it invokes, it should look to a method at the AddressOf ResetComoboBox.

'Declares a delegate sub that takes no parameters  
Delegate Sub ComboDelegate()  

'Loads form and controls  
Private Sub LoadForm(sender As System.Object, e As EventArgs) _  
 Handles MyBase.Load  
 ComboBox1.Items.Add("This is okay")  
 ComboBox1.Items.Add("This is NOT okay")  
 ResetComboBox()  
End Sub  

'Handles Selected Index Changed Event for combo Box  
Private Sub ComboBoxSelectionChanged(sender As System.Object, e As EventArgs) _  
 Handles ComboBox1.SelectedIndexChanged  
 'if option 2 selected, reset control back to original  
 If ComboBox1.SelectedIndex = 1 Then  
  BeginInvoke(New ComboDelegate(AddressOf ResetComboBox))  
 End If  

End Sub  

'Exits out of ComboBox selection and displays prompt text   
Private Sub ResetComboBox()  
 With ComboBox1  
  .SelectedIndex = -1  
  .Text = "Select an option"  
  .Focus()  
 End With  
End Sub  

You’ll notice that when ResetComboBox is eventually called by the delegate, it will also fire the SelectionChanged event when we change the SlectedIndex to -1. If there’s a chance that you’re handling anything in the change event that could cause a repetitive loop, you can include a private cancelAction boolean property in your class, defaulted to False. Then when you start the ResetComboBox method, set cancelAction to True and reset it to False at the end of method. In the selection changed event, exit the sub if cancel action will set and you will never accidentally execute code when you’re resetting controls

If cancelAction Then Exit Sub

Source Code

You can find the source code for this application from SkyDrive. Please comment with any suggestions or questions

Intro

Let’s say you have a list of things displayed in a DataGridView and you want a user to be able to select among them on a DataGridViewCheckBoxColumn. Further, let’s say that you’d like to know as soon as the user has made a change to their selection. You might want to handle this for a number of reasons: to enable a save button, to change the appearance of selected items, to display a pop-up window, or to check for consistency against other choices. It turns out that this is trickier than it might seem and doesn’t work great out of the box from .NET, but, not to fear, there are several easy work-arounds that will get the trick done.

The Problem

'This won't fire until the cell has lost focus
Private Sub DataGridCellValueChanged(sender As DataGridView, 
                                     e As DataGridViewCellEventArgs) _ 
        Handles DataGridView1.CellValueChanged
 IsDirty = True
End Sub

When you click a CheckBox in a DataGridViewCheckBoxColumn, the check marker will update immediately, but CellValueChanged event on the DataGridView will not fire until the user happens to click elsewhere and the cell has lost focus. Why? Well, the DataGridView thinks it’s a little preemptive to go declaring that the cell value has changed while you are still selected on it. This makes more sense when we think about a TextBox column. We would not want the CellValueChanged event firing every single time a letter was added to a person’s last name. Still, it doesn’t make much sense when we think about the way CheckBox’s work, in that, they can only ever be On or Off, and that once you have made your selection, you’re probably pretty confident that you want to change the value. Any solution is going to involve using an event that definitely will fire to stop the DataGridView from thinking it’s in edit mode.

The Solution

This problem was also raised in a StackOverflow Question which seemed to advocate for handling the MouseUp event on the DataGridView and then call the EndEdit method, thereby ensuring that the grid would evaluate whether or not the Cell’s value had, indeed, changed and fire the corresponding event appropriately I must admit, this works, but feels like more of a work around than a solution. What if someone is able to make a selection without a click event? There seems to be a non-zero percent chance that this might fire incorrectly in some unforeseen situation. I’d rather code to do exactly what it says it’s doing.

We could also handle the DataGrid’s CellContentClick event. This has the added bonus of not firing when you have clicked outside of the checkbox area, but still falls perhaps under the same category of not being entirely clear to someone unfamiliar with this issue why this particular event should force the grid to exit edit mode.

After looking into the problem at some length, MSDN actually seems to offer the best solution right on their CellContentClick event page. Here’s a cleaned up version:

'Ends Edit Mode So CellValueChanged Event Can Fire
Private Sub EndEditMode(sender As System.Object, 
                        e As EventArgs) _
            Handles DataGridView1.CurrentCellDirtyStateChanged
    'if current cell of grid is dirty, commits edit
    If DataGridView1.IsCurrentCellDirty Then
        DataGridView1.CommitEdit(DataGridViewDataErrorContexts.Commit)
    End If
End Sub

'Executes when Cell Value on a DataGridView changes
Private Sub DataGridCellValueChanged(sender As DataGridView, 
                                     e As DataGridViewCellEventArgs) _
            Handles DataGridView1.CellValueChanged
    'check that row isn't -1, i.e. creating datagrid header
    If e.RowIndex = -1 Then Exit Sub

    'mark as dirty
    IsDirty = True
End Sub

In the code sample above, we monitor the CurrentCellDirtyStateChanged event. I like that it tells us very specifically what has happened to the grid at the point in time when the event is raised and handled. It’s important to note that this event will get called twice, once on changing the state of the cell to dirty (before committing changes) and once when changing the cell state back to ‘clean’ (after the changes have been committed). For this reason, before preforming any action, it checks to see when the current cell is dirty or not. If it is, it’ll call the CommittEdit method and pass in the DataGridViewDataErrorContexts enumerator type of Commit

Sample / Source Code

I worked up what I hope to be an interesting sample of the different methods by which we can get the CellValueChanged event to eventually fire.

The form loads by default to only handle the CellValueChanged event itself, which means we will immediately notice the problem at hand. Changing the active status for a given person will not fire the event until some other object on the form is clicked and receives focus. Anytime a grid event is handled, a notification will pop-up and fade out. This helps identify when, and in what order, events are being handled without explicitly having to set breakpoints and wait for the code to catch each event.

In the options group box, you can choose to include event handlers notifications or not. Also, the drop down list will add / remove handlers so you can easily test out which handlers do what without having to specifically comment out lines of code.

You can download the mini application and the source code for this demo on SkyDrive or by clicking the icons below: