FWD » Core Development » User Interface

Testcase:

def var fi1 as char view-as fill-in.
def var fi2 as char view-as fill-in.
def var fi3 as char view-as fill-in.

def frame f fi1 at row 1 col 1 fi2 at row 3 col 1 fi3 at row 5 col 1 with side-labels.
enable all with frame f.
wait-for window-close of current-window.

TAB should move the focus on the next tab-stop widget and SHIFT-TAB should do the opposite. In Web ChUI both work, but Swing ChUI just flashes the widget which should receive focus, and then returns the focus on the initial widget. Tested with trunk/rev. 16323.

Do TAB/SHIFT+TAB keys work properly if the client is running on Windows?

Hynek Cihlar wrote:

Is this issue limited only to Shift+Tab?

ATM we only treat the shift+tab combination in keyPressed() and that's why I wrote only its counterpart in keyTyped(). There are probably more cases like this. We could make it general and stop any SHIFT+keys processing from keyTyped() in order to handle it in keyPressed(), but this is prone to errors because we would need to test every possible SHIFT+key combination. So, how do you want to proceed further?

Do TAB/SHIFT+TAB keys work properly if the client is running on Windows?

I can't know that as I don't have the client configured on Windows.

Razvan-Nicolae Chichirau wrote:

Hynek Cihlar wrote:

Is this issue limited only to Shift+Tab?

ATM we only treat the shift+tab combination in keyPressed() and that's why I wrote only its counterpart in keyTyped(). There are probably more cases like this. We could make it general and stop any SHIFT+keys processing from keyTyped() in order to handle it in keyPressed(), but this is prone to errors because we would need to test every possible SHIFT+key combination. So, how do you want to proceed further?

Do TAB/SHIFT+TAB keys work properly if the client is running on Windows?

I can't know that as I don't have the client configured on Windows.

Is it correct that if we choose this configuration option "opsys"="WIN32", then WinKeyboardReader will be used with the Swing client

<parameter name="opsys"            value="WIN32" />

This class represents a {@link SwingKeyboardReader} implementation for clients which require NCURSES/Linux compatibility.

Sergey Ivanovskiy wrote:

Is it correct that if we choose this configuration option "opsys"="WIN32", then WinKeyboardReader will be used with the Swing client

No. You need to have the following node in deploy/client/client.xml:

<node type="client">
   <client>
      <chui windows="true"/>
   </client>
</node>

Do you know/understand what means NCURSES/Linux compatibility?

I guess the compatibility that FWD offers to run a program in an NCURSES-powered terminal / Linux in general (i.e. custom Linux keys behavior).

Do you know/understand what means NCURSES/Linux compatibility?

I guess the compatibility that FWD offers to run a program in an NCURSES-powered terminal / Linux in general (i.e. custom Linux keys behavior).

I meant what is the difference in compare with Windows case or what is the special Linux keys behavior? LinuxKeyboardReader sends key on keypressed if

      Integer mappedCode = xlate.get(key);

      if (mappedCode != null)

The changes 11056a/rev. 16326 looks correct.

Has 11056a passed the review?

Razvan-Nicolae Chichirau wrote:

Has 11056a passed the review?

Yes, I think that the changes are good.

Sergey Ivanovskiy wrote:

Razvan-Nicolae Chichirau wrote:

Has 11056a passed the review?

Yes, I think that the changes are good.

Although there is the following comments in the code

         // normal VK_TAB is generated naturally in keyTyped() but SHIFT +
         // TAB must be handled here
         if (code == Key.VK_TAB)
         {
            code = shift ? Key.VK_BACK_TAB : -1;
         }

Razvan-Nicolae Chichirau wrote:

ATM we only treat the shift+tab combination in keyPressed() and that's why I wrote only its counterpart in keyTyped(). There are probably more cases like this. We could make it general and stop any SHIFT+keys processing from keyTyped() in order to handle it in keyPressed(), but this is prone to errors because we would need to test every possible SHIFT+key combination. So, how do you want to proceed further?

Unless there are more similar customer reports, let's address it case by case for now.

Sergey Ivanovskiy wrote:

This comment supposes that SHIFT+TAB doesn't emit keyTyped event. What should be changed so TAB became emitted?

When you are pressing TAB in the sequence SHIFT+TAB, both keyPressed() and keyTyped() are called in this order.

Hynek Cihlar wrote:

Unless there are more similar customer reports, let's address it case by case for now.

Can this be moved to Internal Testing?

• ChUI regression tests
• Isolated tests such as #11056-1
• Customer app smoke-test

If this is enough, we should merge 11056a.

Razvan-Nicolae Chichirau wrote:

Knowing this affects only Swing ChUI, I've done the following:

• ChUI regression tests
• Isolated tests such as #11056-1
• Customer app smoke-test

If this is enough, we should merge 11056a.

I think this should be enough, but let's wait for Sergey's go.

Sergey, please respond to #11056-18.

It seems that you completed all tests and this branch can be merged.