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,
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.
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.
The "support" Mike refers to here is for product maintenance - in other words, bug fixes. And as usual, he's correct - we currently provide maintenance for NetAdvantage for .NET from versions 7.2 through 8.2.
Developer Support also provides usage support for older versions, up to three years from their release date. This means we can give you implementation suggestions for these versions, and confirm whether or not certain issues are fixed or certain features are available. However, if there's a new bug identified in these older versions, they'll only be fixed in those versions we maintain. Right now, we provide this "usage support" from 5.3 through 8.2.
If you're interested in more details, you can find them on the Product Lifecycle page of our website.
rprussell said: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.)
It depends how old it is. We are currently supporting v7.2 and up, I beleive.
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!