Question

We discovered a possible bug involving the DataGridView. The DataGridView has a property, StandardTab, that is set to False by default. This default setting means that the TAB key moves between cells within the grid. When it reaches the final cell in the grid, then the TAB key moves focus to the next control. This is the setting we are using in our project.

The DataGridView is connected to a binding source in our project, which may or may not be relevant.

When the DataGridView is on a form that is being displayed from a COM-based project (VB6, in our case), the grid control loses focus when the user tries to tab within the grid. If you hold down the tab key, focus cycles through other controls on the form until it returns to the grid. When it returns to the grid, the selected cell is the one that the user was tabbing to.

So, it is possible for the user to navigate through all the cells, via a detour through the rest of the controls on the form as they move from cell to cell. This does not make for happy users.

I did find an MSDN forum question that seems to describe this problem, but the only answer to it is not terribly helpful.

I could submit this as a bug on Microsoft Connect, but I doubt they are going to fix it. Is there a way to deal with this issue in code?

Answer 1

Further investigation of the following events/methods revealed a pattern:
Leave (on the control)
ProcessDialogKey (on the form and on the control)
ProcessDataGridViewKey (on the control)

The last two events turned out to be key to the problem.

When we tested in a 100% .NET project, we discovered that tabbing internally would execute the ProcessDataGridViewKey event to fire. When on the last cell, the ProcessDataGridView function was not executed, but the ProcessDialogKey function was executed.

When we tested in the Interop project, the events were exactly the same, but a Leave event on the control occurred before the ProcessDataGridViewKey function was executed. The bad scenario is unique in that the control will not have focus then ProcessDataGridViewKey function is executed.

Perhaps we can test for that and make focus come back to the control? It turns out that we can, and here is a subclassed control that handles it, yet still works fine in a 100% .NET project.

Public Class DataGridViewCustom : Inherits DataGridView
    Protected Overrides Function ProcessDataGridViewKey(e As System.Windows.Forms.KeyEventArgs) As Boolean
        ' When the grid is hosted by a form that is being loaded through the Interop Forms Toolkit,
        ' the default behavior of using the TAB key to navigate between cells is broken 
        ' (StandardTab = False). The tab key causes the grid control to lose focus before it has a 
        ' chance to process the tab key in this event handler.
        '
        ' This handler is not executed when the TAB key is supposed to make it lose focus (i.e. when
        ' StandardTab is True or when TABbing off the last cell within the grid). In those 
        ' scenarios, the ProcessDialogKey event handler is executed, and there is no problem.
        ' Therefore, we can assume that if this event is being processed, and the grid does not have
        ' focus, we should put focus back on the control.

        ' The datagridview has different behavior for TAB and CTL-TAB, depending on how the StandardTab
        ' property is set. We don't have to worry about that becuase this method only executes when the
        ' focus is supposed to stay within the control. A different method is executed when the focus
        ' is supposed to leave the control.

        If e.KeyCode = Keys.Tab AndAlso Not Me.Focused Then Me.Focus()

        Return MyBase.ProcessDataGridViewKey(e)
    End Function
End Class