lwuit
  1. lwuit
  2. LWUIT-429

Listen to soft keys on dialog/form

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Hi,

      it is impossible to use the addKeyListener to detect soft key presses on dialogs/forms
      since the keyReleased method in form calls the menubar if they detect soft key codes and does a return (even if there are no commands on the menubar.
      In general i think the keyPressed/KeyReleased etc methods should return a boolean to know if the event was consumed or not thus allowing to continue propagate or not onwards.
      We have our own UI lib that we build and we also did at first the mistake of not using a boolean on the return value, however this change might be too big atm for lwuit so perhaps the call the keylisteners at the start of the function or perhaps not doing a return.
      i would also like to explain the underline cause to which we want to listen to soft keys.
      we use dialogs to show the user ok/cancel questions etc and when the ok/cancel are used as soft keys they look a bit ugly and not connected to the actual dialog itself and its also not so friendly to touch devices. we saw there is a theme constant that allow the commands to be shown as buttons on the dialog but they dont respond to their relative soft keys to allow for both touch and non-touch devices to use it in intuitive manner so we tried adding our own buttons and using the keylistener to connect the soft keys to the buttons.

      (sorry for the looooooooooooooong explanation)

        Activity

        Hide
        vprise added a comment -

        I'm marking this as fixed since I changed the behavior of commandsAsButtons to check the softbuttons internally and perform the command when a physical softbutton is pressed.

        We have event.consume() the approach of returning false from a method is only practical for simpler API's that don't rely on the observer pattern. Even in this case its a problem since people need to be familiar with the call chain of event dispatch.

        We don't expose softbuttons since we don't want people to "hack" them, they are a problematic none-portable concept. If you really want to get access to them you should replace the menu bar (which we now allow).

        Show
        vprise added a comment - I'm marking this as fixed since I changed the behavior of commandsAsButtons to check the softbuttons internally and perform the command when a physical softbutton is pressed. We have event.consume() the approach of returning false from a method is only practical for simpler API's that don't rely on the observer pattern. Even in this case its a problem since people need to be familiar with the call chain of event dispatch. We don't expose softbuttons since we don't want people to "hack" them, they are a problematic none-portable concept. If you really want to get access to them you should replace the menu bar (which we now allow).
        Hide
        tempusername added a comment -

        Hi,

        Was this change committed? i updated my src two days ago and i dont think its working.

        Show
        tempusername added a comment - Hi, Was this change committed? i updated my src two days ago and i dont think its working.
        Hide
        vprise added a comment -

        Yes: Dialog.java lines 919-935

        Show
        vprise added a comment - Yes: Dialog.java lines 919-935

          People

          • Assignee:
            Unassigned
            Reporter:
            tempusername
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: