Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 328563 - Grid consumes all "arrow" keys
Summary: Grid consumes all "arrow" keys
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Nebula (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P5 minor with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Mirko Paturzo CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-25 02:16 EDT by Peer Törngren CLA
Modified: 2021-07-05 11:39 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peer Törngren CLA 2010-10-25 02:16:52 EDT
Build Identifier:  20100617-1415

For accessibility and general usability reasons, I wish to map some keys to handle "move row" on the grid. The grid uses "UP/DOWN" with CTRL or SHIFT to do select and focus operations, and the plain keys (without modifiers) to do traversal. Since the ALT+UP/DOWN keys are unused by the grid, I thought I'd use these. 


Alas, the way that the grid listens to key events prevents this; it does special handling of both CTRL and SHIFT, and defaults to "traversal". I can add the key listener and have it do what I want, but cannot prevent the traversal operation. Also, since the Grid gets notified first, I cannot "consume" the event by setting "KeyEvent.doit" to false. I can get the desired behavior by using other keys (e.g. ALT+NUMPAD_8 and ALT+NUMPAD_2).

The problem seems to be located to org.eclipse.nebula.widgets.grid.Grid.onKeyDown(Event), where the UP/DOWN key behaves the same way whether or not the ALT (MOD3) key is used. 

I can see two solutions:
a) make org.eclipse.nebula.widgets.grid.Grid.onKeyDown(Event) ignore keys if an undefined modifier (such as MOD3) is used
b) make Grid consume key events last in chain, allowing externally added listeners to prevent grid default actions by setting 'KeyEvent.doit=false'


Reproducible: Always

Steps to Reproduce:
1. Grid myGrid = new Grid(....)
2. myGrid.addKeyListener(new KeyListener(...) {
   public void keyPressed(KeyEvent e): 
       switch (e.keyCode) {
       case SWT.ARROW_UP:
           if ((e.stateMask & SWT.ALT) != 0) {
               doMyStuffInsteadOfTraversing();
               e.doit = false;
           }
	break;
<snip>
Comment 1 Markus Stier CLA 2012-04-20 11:14:11 EDT
Any chance for progress here?
Comment 2 Mirko Paturzo CLA 2014-03-28 07:03:39 EDT
Hi Peer,
Now grid implement a method called disableDefaultKeyListener. With this method you can disable grid default key listener.

If Grid method onKeyDown(Event e) change visibility from private to protected, you can extend your own Grid and use method such as:

example:

class MyGrid extends Grid {
     protected void onKeyDown(Event e) {
        case SWT.ARROW_UP:
           if ((e.stateMask & SWT.ALT) != 0) {
               doMyStuffInsteadOfTraversing();
           }
           else
           super.onKeyDown(Event e);
	break;
     }
}

or something else..
Comment 3 Thomas Schindl CLA 2014-03-28 07:08:08 EDT
SWT in general does not use subclassing because it is much harder to evolve API if you allow subclassing - I'd rethink the API in this regard so that subclassing is NOT needed!
Comment 4 Mirko Paturzo CLA 2014-03-28 07:20:44 EDT
Thanks for the tip. I will work in the direction you just suggested.
Comment 5 Wim Jongman CLA 2014-03-28 11:34:33 EDT
(In reply to Thomas Schindl from comment #3)
> SWT in general does not use subclassing because it is much harder to evolve
> API if you allow subclassing - I'd rethink the API in this regard so that
> subclassing is NOT needed!

Would it really be a problem in this case?
Comment 6 Mirko Paturzo CLA 2014-05-06 09:27:17 EDT
Hi all,
Now in git master there is a patch with protected method. We can resolve this bug or reimplement again: What do you think?
Comment 7 Mirko Paturzo CLA 2017-04-14 05:07:56 EDT
Hi all,
reminder.. I think that, this bug must be closed because a patch is already developed..
Thanks all
Mirko
Comment 8 Wim Jongman CLA 2017-04-14 05:18:23 EDT
(In reply to Mirko Paturzo from comment #7)
> Hi all,
> reminder.. I think that, this bug must be closed because a patch is already
> developed..
> Thanks all
> Mirko

Hi Mirko you are the owner of the bug. Please go ahead and close if you think it should.