Bug 424133 - Key event should be fired if active_key is registered on parent widget of focused control
Summary: Key event should be fired if active_key is registered on parent widget of foc...
Status: NEW
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: 2.2   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-16 10:17 EST by Claudio Guglielmo CLA
Modified: 2014-01-09 09:40 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Claudio Guglielmo CLA 2013-12-16 10:17:06 EST
When using RWT.ACTIVE_KEY, the keystroke listener is only executed if the keystroke is registered on the focused control. This is fine if the keystroke is only used for a specific control. 

In our case we would like to register a keystroke for a composite which may contain multiple controls. At the moment we have to register the same keystroke on every control. It works but I am unsure if it's the way to go. In my opinion it would be better if the javascript code checked the parent controls of the focused one as well. With this solution one could reduce the transmitted data a little.

If you don't agree, feel free to close the ticket.
Comment 1 Tim Buschtoens CLA 2014-01-09 04:59:55 EST
I like the idea, but I also see a potential for breaking existing code when changing this behavior. When someone currently sets ACTIVE_KEYS on a Composite, it would not have any effect unless the Composite is forced to be focused (I think that's possible). Also, what would happen if you have ACTIVE_KEYS set on both parent and child?
Comment 2 Ralf Sternberg CLA 2014-01-09 09:40:43 EST
(In reply to comment #1)
Good point.

The idea behind supporting ACTIVE_KEYS on controls was to be able to limit the number of requests that are sent for key events to those keys that the listener code is actually interested in. I'd think that this is related to a type of widgets more than to the parent hierarchy. Could you explain your use case a little more?