|
Re: [neon] vs [mars] Difference in Keystroke Handling [message #1749910 is a reply to message #1749580] |
Tue, 13 December 2016 17:34 |
|
Hi Urs
Most inner KeyStrokes are automatically "pulled up" to the surrounding form. Why's that? Consider a form with two group boxes below each other and the second group box defining a key stroke. To make the key stroke work while the current input focus is on a field inside the first group box, the UI handles it as if it was defined on the form itself. (Different forms are still isolated from each other.) This works well in most cases, but unfortunately not if the same key combination is used on two different key strokes on the same form.
Anway, Scout should not use one or the other behavior without providing a way to programmatically change it. AbstractButtons have the method "getConfiguredKeyStrokeScopeClass()" to manually change the context in which the button's key stroke are active. Unfortunately, we did not implement this feature for AbstractActions. (Buttons not being Actions is another unfortunate technical dept we want to get rid off, but there is no planned date for this feature yet.)
Right now it is the expected behaviour that both key strokes fire (because they have the same key sequence). That only the first key stroke fires until you have visited the second tab is an actual bug (for which you may file a Bugzilla ticket), but it should not really affect you. The proposed workaround for your case would be to add checks in the model code. So both key strokes will fire, but only one will execute it's action. Example:
public class ClearKeyStroke extends AbstractKeyStroke {
protected String getConfiguredKeyStroke() {
return "Ctrl-0";
}
protected void execAction() {
if (getTabBox().getSelectedTab() != AbcBox .this) { // <==
return; // tab is not active
}
getFirstField().setValue(null);
}
}
Would that be an acceptable workaround?
Regards,
Beat
|
|
|
|
Powered by
FUDForum. Page generated in 0.02741 seconds