Hi, all -
We have a number of bands in our grid and not every cell "does something" - some are just for show. So I am writing a custom KeyDown handler for the grid where it looks for Tab (or shift-Tab) and figures out which is the next cell to move to based on what's expanded and what exists. Then at the end of the "which cell are we gonna move to" block, there's a single block to activate the cell, which looks like:
If newRow IsNot Nothing Then _MapGrid.ActiveRow = newRow newRow.Cells(Col).Activate() ' _MapGrid.ActiveCell = newRow.Cells(Col)
If newRow.Cells(Col).CanEnterEditMode Then _MapGrid.PerformAction(UltraGridAction.EnterEditMode) e.Handled = True e.SuppressKeyPress = True System.Diagnostics.Debug.WriteLine("After tab: New cell is " & Col & " and activated is " & newRow.Cells(Col).Activated) End If
"newRow" is the row we've decided to move to (either forward OR backward) and "Col" is a string containing the name of the column to activate. Forward-tabbing works fine and will find and activate the correct cell when moving from one row to the next, or one band to the next.
Shift-tabbing does not. For whatever reason, the "newRow.Cells(Col).Activate" call isn't "sticking." I can put a breakpoint immediately after it and check the active status of the cell, and it will still report "False." I also tried assigning _MapGrid.ActiveCell (its commented out in the sample above.)
So, my questions are:
1) What on earth would make this work when tabbing in one direction but not the other? How can I make it stop doing this?
2) What (also on earth) would keep the ".Activate" call from not taking effect? and of course
3) How do I fix it? ;)
Interestingly, I've seen similar ignoring of a call happen when trying to expand parent bands - I'll call "ExpandAll" and it will simply ignore it, leaving the branch collapsed.
Thanks a bunch,
Rob
Hi Rob,
I'm not sure exactly what's going on there. If I had to guess. I'd say that it may have something to do with it being 2 keys instead of 1. Perhaps your check for the keycode isn't quite right, or perhaps something is weird with the way the Handled param is working.
If you can duplicate the issue in a small sample project, you can Submit an incident to Infragistics Developer Support and they will be happy to check it out.
But, I am wondering if you are working too hard at this. It seems to me that this could be done a lot more easily. Are you aware that the grid column has a TabStop and TabIndex property? So you can control which columns can be tabbed to and in what order the tabbing works without writing a lot of code.
If your situation is more complicated than that, then I would recommend using the grid's BeforePerformAction event. This event will give you the action being performed. In your case, you would look for NextCell/PreviousCell. Or maybe it's NextCellByTab/PreviousCellByTab. You could cancel the event and then do what you are doing now, and hopefully if I am right about the keystrokes being the issue, it will work better.
Hi, Mike -
Same behavior (ignoring "activate" and "entereditmode" calls) whether trapping it via KeyPress or BeforePerformAction.
Setting the tabstops and tab indexes worked going forward but not going backward, and going between bands was sketchy - sometimes it would go to a child band with one "tab," sometimes it would take two, and my debug trace would show it trying to do a NextCellByTab (into nowhere?) and then a NextRowByTab on the 2nd press, which would activate the next row.
Going backward with tabstops and indices would tab from cell to cell in a single row, but not move to the previous row whether or not it was in the same band - it would end up activating the entire row, but not the last cell in it.
I've gotten the closest approximation to what I need by handling the BeforePerformAction event, calculating the appropriate row/column to move to, setting two global members to 'save' these values, and starting a timer to activate them. The timer ticks every 10th of a second and tries to activate the saved row/col, generally succeeding within two ticks. One thing I have noticed is that it will NOT succeed until I let up on the shift key, and I wonder if that's related to the original failure of a cell to activate at all.
I'll keep plugging along. I honestly wish that I had the time and resources to put together a sample/test/incident project for this, but deadline, pressure, etc etc. It's with version 7.3.
That's a lot of very odd behavior going on there. Unfortunately, I can't explain it. I've never had any trouble with this sort of thing - especially when using BeforePerformAction.
The behavior you are getting sounds to me like maybe you are not always cancelling the event when you need to. Or that you are calling PerformAction and not handling the recusrive calls to BeforePerformAction that will occur as a result.
Keep in mind that a single keystroke may result in multiple actions being performed. When you press a key, the grid will examine all of it's KeyActionMappings to see which ones are valid for the keystroke and the current state. It will then perform all of the actions in sequence. So perhaps you are handling one action and then a subsequent action is messing things up.