Focusverhalten und wechsel des KeyboardFocusManagers

[Bert Brenner]

Mein Problem tritt nur unter Windows auf bei verwendung des Windows Look&Feels.

In einem Projekt bei uns ist es erforderlich den KeyboardFocusManager gegen einen eigenen zu tauschen, jedoch für z.b. Dialoge soll wieder der DefaultKeyboardFocusManager zum Einsatz kommen.

Wechselt man den Manager wie im Beispiel unten, kann man nicht mehr per TAB-Taste zwischen den Buttons des Dialoges wechseln.
Was übersehe ich hier?

Hier ein minimales Beispielprogramm um mein Problem nachzustellen:

import java.awt.*;
import javax.swing.*;

public class DialogTest {
  public static void main(String[] args) throws Exception {
    UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
    KeyboardFocusManager.setCurrentKeyboardFocusManager(null);

    int result = JOptionPane.showConfirmDialog(null, "Was geht?");
    
    System.out.println(result);
    System.exit(0);
  }
}

 

[Gast2]

Wie soll ohne KeyboardManager auch irgendwelche Keyanschläge(Tab) an deiner GUI ankommen?
Du solltest ihn auf keinen Fall auf null setzen... Und auch nicht überschreiben oder sonstiges...

Wenn du schon sowas machen willst musst du dir den alten schon gescheit merken irgendwo und diesen dann setzen

    KeyboardFocusManager oldManager = KeyboardFocusManager.getCurrentKeyboardFocusManager();
    KeyboardFocusManager.setCurrentKeyboardFocusManager(oldManager);

 

[Bert Brenner]

Nach der API wird bei übergabe von null ein neuer DefaultKeyboardFocusManager erzeugt.
Und das Problem tritt ja nur unter Windows auf, wenn das Windows Look&Feel verwendet wird.

Ich werds wohl so machen, das ich mir einfach die erste Instanz des KeyboardFocusManagers irgendwo merke um diesen dann immer scharf zu machen wenn er gebraucht werden sollte.

 

[Ebenius]

Wie soll ohne KeyboardManager auch irgendwelche Keyanschläge(Tab) an deiner GUI ankommen?

In die Falle wäre ich auch fast getappt, hab dann aber lieber nochmal in der API-Doc gelesen. Der Themeneröffner hätte das natürlich auch im Eingangsbeitrag erwähnen können, um uns nicht auf's Glatteis zu führen. ;-)

Ebenius

 

[Gast2]

In die Falle wäre ich auch fast getappt, hab dann aber lieber nochmal in der API-Doc gelesen. Der Themeneröffner hätte das natürlich auch im Eingangsbeitrag erwähnen können, um uns nicht auf's Glatteis zu führen. ;-)

Ebenius

hä welche Falle meinst du?

 

[Ebenius]

hä welche Falle meinst du?

Die, zu denken, dass [c]KeyboardFocusManager. setCurrentKeyboardFocusManager(null)[/c] nicht den Default-FocusManager setzt. Siehe API-Doc:

Sets the current KeyboardFocusManager instance for the calling thread's context. If null is specified, then the current KeyboardFocusManager is replaced with a new instance of DefaultKeyboardFocusManager.

Ebenius

 

[Gast2]

Ja mein ich doch er soll nicht null rein setzen, sondern sich den alten merken...