Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » [neon] vs [mars] Difference in Keystroke Handling
[neon] vs [mars] Difference in Keystroke Handling [message #1749580] Thu, 08 December 2016 10:14 Go to next message
Urs Beeli is currently offline Urs BeeliFriend
Messages: 567
Registered: October 2012
Location: Bern, Switzerland
Senior Member
We have a form with roughly the outline described below.

In Mars we have the following behaviour:

  • show AbcBox by choosing the corresponding tab
  • press "Ctrl-1" -> FirstField is filled with "AAA"
  • show DefBox by choosing the corresponding tab
  • SecondField is still empty
  • press "Ctrl-1" -> SecondField is filled with "BBB"
  • press "Ctrl-0" -> SecondField is cleared
  • switch back to AbcBox
  • FirstField still contains "AAA"


Doing the same with Neon, pressing Ctrl-1 or Ctrl-0 only have an effect if we click into one of the string fields after switching tabs. However, once after that, the keystrokes in both the AbcBox and DefBox are executed, so it is no longer possible to just populate/clear the fields in one tab box.

Is this intended behaviour or have we discovered a bug? If the former, how can we re-enable the Mars-like behaviour? If the latter, I will open a bug report.

public class SomeForm extends AbstractForm {
  public class MainBox extends AbstractGroupBox {
    public class TabBox extends AbstractTabBox {
      public class AbcBox extends AbstractGroupBox {
        public class ClearKeyStroke extends AbstractKeyStroke {
          protected String getConfiguredKeyStroke() {
            return "Ctrl-0";
          }
          protected void execAction() {
            getFirstField().setValue(null);
          }
        }
        public class PopulateKeyStroke extends AbstractKeyStroke {
          protected String getConfiguredKeyStroke() {
            return "Ctrl-1";
          }
          protected void execAction() {
            getFirstField().setValue("AAA");
          }
        }
        public class FirstField extends AbstractStringField {
        }
      }

      public class DefBox extends AbstractGroupBox {
        public class ClearKeyStroke extends AbstractKeyStroke {
          protected String getConfiguredKeyStroke() {
            return "Ctrl-0";
          }
          protected void execAction() {
            getSecondField().setValue(null);
          }
        }
        public class PopulateKeyStroke extends AbstractKeyStroke {
          protected String getConfiguredKeyStroke() {
            return "Ctrl-1";
          }
          protected void execAction() {
            getSecondField().setValue("BBB");
          }
        }
        public class SecondField extends AbstractStringField {
        }
      }
    }
  }
}
Re: [neon] vs [mars] Difference in Keystroke Handling [message #1749910 is a reply to message #1749580] Tue, 13 December 2016 17:34 Go to previous messageGo to next message
Beat Schwarzentrub is currently offline Beat SchwarzentrubFriend
Messages: 90
Registered: November 2010
Member
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
Re: [neon] vs [mars] Difference in Keystroke Handling [message #1749955 is a reply to message #1749910] Wed, 14 December 2016 13:19 Go to previous message
Urs Beeli is currently offline Urs BeeliFriend
Messages: 567
Registered: October 2012
Location: Bern, Switzerland
Senior Member
Hi Beat

Thanks for confirming the behaviour I observed. It seems that the paradigm of "pulling up" keystrokes changed from Mars to Neon. The bug of the second keystroke only firing after switching to that tab for the first time is actually more of a feature for me Wink

I'll add the workaround you proposed, that should solve my immediate problem.

Cheers
/urs
Previous Topic:Scout Neon & Testing
Next Topic:File upload widget
Goto Forum:
  


Current Time: Tue Nov 21 04:49:35 GMT 2017

Powered by FUDForum. Page generated in 0.01426 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software