Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #39983 > unrolled thread

Default Button Doesn't Follow Focused Button

Back to article view | Back to comp.lang.java.programmer

Contents

  Default Button Doesn't Follow Focused Button Andreas Leitgeb <avl@logic.at> - 2023-07-26 16:15 +0000
    Re: Default Button Doesn't Follow Focused Button "e.d.pro...@gmail.com" <e.d.programmer@gmail.com> - 2023-07-26 10:59 -0700
      Re: Default Button Doesn't Follow Focused Button Andreas Leitgeb <avl@logic.at> - 2023-07-26 19:01 +0000
        Re: Default Button Doesn't Follow Focused Button Andreas Leitgeb <avl@logic.at> - 2023-07-27 07:12 +0000
          Re: Default Button Doesn't Follow Focused Button "e.d.pro...@gmail.com" <e.d.programmer@gmail.com> - 2023-07-27 10:57 -0700

#39983 — Default Button Doesn't Follow Focused Button

Imagine a simple Dialog (SSCCE at the bottom of this post)
with just two buttons, one of which is initially set up as
Default-button, such that a simple <Return>-key press would
invoke it.

In Windows, it seems to be "usual behaviour" that if I now 
use the Tab-key to set focus on any other button, then the
focused button should temporally become the new "default"-
button, until focus goes to something not-a-button, then the
original default button would receive the blue frame again
and become default again.

As it seems, Java does not follow this principle: instead, 
one button is declared as default, and regardless of whether
the focus is on a different button or not, <Return>-key would
always invoke the initially set default button.


Has anyone here ever needed to change his Java program to be
less alien on Windows in that matter?

Will I need to install Focus listeners on each component, and
set the defaultButton to either the focused component (if it
is a button), or the dialogs initial default (otherwise)?



--- SSCCE ---

Even when running it on Windows, the blue frame of the default 
button doesn't follow the focus when Tabbing.  When Focus is moved
to the Ok-button, the blue frame stays around the Cancel button.

--- begin - Test.java ---
import javax.swing.JOptionPane;

public class Test
{
   public static void main(String[] args)
   {
      JOptionPane.showOptionDialog(null,
         "My Message", "My Message Dialog",
         JOptionPane.OK_CANCEL_OPTION,
         JOptionPane.INFORMATION_MESSAGE,
         null, new String[]{"Ok", "Cancel"},
         "Cancel");
      System.exit(0);
   }
}
--- end ---

[toc] | [next] | [standalone]

#39984

On Wednesday, July 26, 2023 at 12:15:42 PM UTC-4, Andreas Leitgeb wrote:
> Imagine a simple Dialog (SSCCE at the bottom of this post) 
> with just two buttons, one of which is initially set up as 
> Default-button, such that a simple <Return>-key press would 
> invoke it. 
> 
> In Windows, it seems to be "usual behaviour" that if I now 
> use the Tab-key to set focus on any other button, then the 
> focused button should temporally become the new "default"- 
> button, until focus goes to something not-a-button, then the 
> original default button would receive the blue frame again 
> and become default again. 
> 
> As it seems, Java does not follow this principle: instead, 
> one button is declared as default, and regardless of whether 
> the focus is on a different button or not, <Return>-key would 
> always invoke the initially set default button. 
> 
> 
> Has anyone here ever needed to change his Java program to be 
> less alien on Windows in that matter? 
> 
> Will I need to install Focus listeners on each component, and 
> set the defaultButton to either the focused component (if it 
> is a button), or the dialogs initial default (otherwise)? 
> 
> 
> 
> --- SSCCE --- 
> 
> Even when running it on Windows, the blue frame of the default 
> button doesn't follow the focus when Tabbing. When Focus is moved 
> to the Ok-button, the blue frame stays around the Cancel button. 
> 
> --- begin - Test.java --- 
> import javax.swing.JOptionPane; 
> 
> public class Test 
> { 
> public static void main(String[] args) 
> { 
> JOptionPane.showOptionDialog(null, 
> "My Message", "My Message Dialog", 
> JOptionPane.OK_CANCEL_OPTION, 
> JOptionPane.INFORMATION_MESSAGE, 
> null, new String[]{"Ok", "Cancel"}, 
> "Cancel"); 
> System.exit(0); 
> } 
> } 
> --- end ---
There is only supposed to be one default button. Focused button is a different matter. Use space bar to select focused button with keyboard.

[toc] | [prev] | [next] | [standalone]

#39985

e.d.pro...@gmail.com <e.d.programmer@gmail.com> wrote:
> On Wednesday, July 26, 2023 at 12:15:42 PM UTC-4, Andreas Leitgeb wrote:
>> In Windows, it seems to be "usual behaviour" that if I now 
>> use the Tab-key to set focus on any other button, then the 
>> focused button should temporally become the new "default"- 
>> button, until focus goes to something not-a-button, then the 
>> original default button would receive the blue frame again 
>> and become default again. 

> There is only supposed to be one default button. Focused button
> is a different matter. Use space bar to select focused button
> with keyboard.

Yeah, count me in the choir for that preaching...

Unfortunately, the customers refuse to sing along with us.

[toc] | [prev] | [next] | [standalone]

#39986

Problem is solved!

The culprit was in very old parts of the code, where my predecessor-
programmers explicitly thwarted Windows laf default behaviour, by
defining all (except the chosen one) as non-defaultCapable.
They were the same who explicitly selected windows laf, but really
only wanted the look, not the feel - well, not all of it, at least.

The reason, I fooled myself into thinking my SSCCE would be relevant
is, that Java here isn't locally configured for windows l&f, so my
SSCCE picked some other laf, and that other laf just didn't have
the "default follows focused buttons"-behaviour in the first place.




Andreas Leitgeb <avl@logic.at> wrote:
> e.d.pro...@gmail.com <e.d.programmer@gmail.com> wrote:
>> On Wednesday, July 26, 2023 at 12:15:42 PM UTC-4, Andreas Leitgeb wrote:
>>> In Windows, it seems to be "usual behaviour" that if I now 
>>> use the Tab-key to set focus on any other button, then the 
>>> focused button should temporally become the new "default"- 
>>> button, until focus goes to something not-a-button, then the 
>>> original default button would receive the blue frame again 
>>> and become default again. 
>
>> There is only supposed to be one default button. Focused button
>> is a different matter. Use space bar to select focused button
>> with keyboard.
>
> Yeah, count me in the choir for that preaching...
>
> Unfortunately, the customers refuse to sing along with us.
>

[toc] | [prev] | [next] | [standalone]

#39988

On Thursday, July 27, 2023 at 3:12:48 AM UTC-4, Andreas Leitgeb wrote:
> Problem is solved! 
> 
> The culprit was in very old parts of the code, where my predecessor- 
> programmers explicitly thwarted Windows laf default behaviour, by 
> defining all (except the chosen one) as non-defaultCapable. 
> They were the same who explicitly selected windows laf, but really 
> only wanted the look, not the feel - well, not all of it, at least. 
> 
I normally just set the L&F for the graphics. You can override key behavior with listeners. I wouldn't recommend it.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web