I agree that selection will need customization in many cases, but I
also think that a reasonable standard selection implementation that
supports commonly found behavior and can then be customized would go a
long way. It would work out of the box for folks that are happy to
just use the default and serve as reference for others.
Selection through keyboard only is what I was referring to. I see the
ctrl-a support in example 4 and I noticed that it only works when I
first click on a cell that is editable as that seems to direct the
focus to the table. ctrl-a won't work if I simply select a row by
clicking on the id column, the browsers default select behavior will
kick in.
I have a table that does not allow editing, but I need keyboard-select-
navigation. How do I go about the focus issue, how do I make sure the
select handler is actually invoked?
BTW SlickGrid is a really promising plug-in, I managed to get all
other function of my AJAX app work with it, performance rocks and I'm
looking forward to start using it everywhere else as soon as I get a
handle on the select and keyboard navigation issue.
Thanks!
Thomas
On Feb 12, 10:34 pm, Michael Leibman <michael.leib...@gmail.com>
wrote:
> Thomas,
> Row selections is something that needs to be handled differently depending
> on the requirements. Everybody needs something different - whether or not
> to do drag-selects, whether or not to do CTRL/SHIFT key handling, whether or
> not to allow multiple ranges, etc. I am considering adding a "selection"
> behavior to column options (much like how the row reorder is implemented
> now), but I don't have a specific timeline in mind for this. Either way,
> the "custom code" is only about a dozen lines and is extremely
> straightforward :)
>
> What do you mean by "key navigation"?
>
container.find(".grid-canvas").focus();
It is not pretty but works.
The next problem I run into is that in handleKeyDown the onKeyDown
handler is not called unless there is a current row:
handleKeyDown = function handleKeyDownFn(e) {
// do we have any registered handlers?
if (self.onKeyDown && data[currentRow]) {
Shouldn't that currentRow check be left to the onKeyDown handler?
Alternatively, what is recommended way to control currentRow when no
cell editing is used?
To answer your immediate question, the current onKeyDown event is
meant to be used on cells and not on the grid itself, hence the check
for the current cell. You don't have to be using cell editing for
that to work, simply set options.enableCellNavigation to true.
In rev 70a7a6e I had to comment out the currentRow check for the
onKeyDown handler to take effect. Despite of having
options.enableCellNavigation enabled. Perhaps that has changed in the
latest version, I was not able to try that yet. I have to replace all
$. and $( with jQuery. as the $ symbol is already taken in the app I'm
working on.
If you are interested I can send you the keyboard navigation selection
handler code that I have so far. I also had to add a customization to
the core script to be able to call a handler on column resize as I
need to persist the settings.