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.
Hi, Mike!
Well, I'm able to trace into the code and it's hitting the correct lines to figure out which row/column to activate... and I can view the actual row and column objects and have verified that they're the ones I want... it just utterly ignores the "Activate" call.
I will absolutely check out the tabstop/tabindex properties. It sounds like that's exactly what the doctor ordered.
We're not using the latest-and-greatest suite, so my recollection is that the dev support folks will just advise we upgrade. (Can't at the moment.)
But I ought to be able to make some headway with the hints you've given. I'll let you know how it goes.
Thanks!