Any Key Triggers Inline Editing

Any Key Triggers Inline Editing

MrNazgulMrNazgul Posts: 8Questions: 4Answers: 2

When using Editor with KeyTable, pressing most any key will trigger inline editing. I noticed this when I used my "Next Song" media key and happened to have a cell focused. I would think it to be more logical for alpha/numeric/symbol keys to initiate an edit as well as {Enter}, {Backspace}, {Spacebar}, and {Del}. I've experimented and it works with a surprising number of keys including the following:

Problematic Keys:
{Num Lock}, {Caps Lock}, {Scroll Lock}
Various media keys including Right Context Menu, Vol+/-, Mute etc.

You get the idea. :smile:

You can see this behavior on this page:

I have looked at key for KeyTable since documentation states it will pick up keys that are not handled by KeyTable. I don't get callbacks for the various navigation keys like {TAB}, {Arrows}, {HOME}, {PgUp} but I do get callbacks with the problematic keys listed above. By this point the inline edit has already been triggered.

It's easy to workaround this in the key callback by filtering what keys I expect to trigger inline editing and using close() for anything else. I figured at some point it would make sense to have a more logical baseline for what keys would initiate an inline edit.

I'm positive this will land far down on one of your lists (as it should being there's a workaround) but just throwing it out there. :smiley:

This question has an accepted answers - jump to answer


  • allanallan Posts: 61,003Questions: 1Answers: 9,949 Site admin
    Answer ✓

    Thanks for posting this! I'll get it fixed for the next release of KeyTable.


  • MrNazgulMrNazgul Posts: 8Questions: 4Answers: 2

    @allan I had some additional thoughts that may warrant bearing in mind relating to this fix.

    As I mentioned, the key documentation seems to indicate this callback should get fired off only when a key is pressed that Key Table doesn't consume. Based on behavior I see, this seems to mean the navigation keys ({Arrows], {Tab}, {Home}, {End}, {PgUp}, {PgDn}). I think this is reasonable, though there is a bit of goofiness using {Shift+Tab} to navigate in reverse as the {Shift} key will trigger the key, but such things are difficult to avoid.

    I'm presuming (and hoping) you're not going to add {Enter}, {Backspace}, {Spacebar}, and {Del} to get swallowed up by Key Table. I indicated above those would seem to be reasonable keys that could begin editing a cell as they already do. I also think it's reasonable that they continue to show up in the key so that things like originalEvent.preventDefault() can be done. I make use of this to prevent users from deleting out dates by pressing {Del} or {Backspace} when a cell is focused but an inline edit isn't in progress.

    My two cents. If you decide differently, I'm hoping there will be a type of key created on the Key Table level to allow us to intercept keys that would be consumed by Key Table in order to tweak behavior.

This discussion has been closed.