Auslösung von Aktionen über Tastatur (Netbeans)

[jupp61]

Hallo,
ich habe meine Entwicklungsumgebung von Eclipse auf Netbeans umgestellt. Dort ist ja gleich die Erstellung von grafischen Oberflächen leicht möglich.

Allerdings habe ich bei der Erstellung der "mitgelieferten" Muster festgestellt, dass z.B. Buttons nicht mit der Enter-Taste sondern mit der Space-Taste ausgelöst werden. Das finde ich äußerst gewöhnungsbedürftig. Ist das änderbar? Habe ich was vergessen?

Vielen Dank für Unterstützung.

Gruß
Jupp

 

[The_S]

Ne, das is das Standard-Java verhalten und eigentlich überall so . Du könntest die ActionMap bearbeiten, wenn ich das richtig im Kopf habe.

 

[jupp61]

Hallo,
bin noch kein alter Java Hase. Kannst du das etwas genauer erläutern? Beispiel?

Wäre toll.

Danke
Jupp

 

[Wildcard]

Wie Buttons aktiviert werden hängt vom Look and Feel ab.
Gnome -> Leertaste
Java Cross Platform Look and Feel -> Leertaste
Windows -> Enter

 

[jupp61]

Also aktuelles IST bei meinem Testprogramm ist die Leertaste und zwar unter Windows. Und nun?

Thanks for help
Jupp

 

[Wildcard]

Weil du nicht das System Look and Feel verwendest, sondern das Java Cross Platform Look and Feel.

 

[jupp61]

Danke für Hinweis. Hat funktioniert mit:

   private void setLookAndFeel(){
      	// Hilfsroutine für das Erscheinungsbild
	// ermittlen Fensterstil der Plattform
	try{
		UIManager.setLookAndFeel(
				UIManager.getSystemLookAndFeelClassName());
		SwingUtilities.updateComponentTreeUI(this);
	}catch (Exception e){
		System.err.println("Couldn't use the system look and feel :" + e);
	}
    }

leider nur für das Hauptfenster im Programm.

Wie kann ich das auch für ein Sub-Fenster gelten lassen?

Prog-Struktur

public class FMain extends javax.swing.JFrame {
    
    /** Creates new form FMain */
    public FMain() {
        super("Hauptwindow");
        initComponents();
        centerWin(this);
        setLookAndFeel();
    }


    private void openSubWin(java.awt.event.ActionEvent evt) {                                          
// Fenster für die Eingabe im Sub-Winöffnen
        setLookAndFeel();
        JFrameSubWin.setVisible(true);
    }

Danke für Support
Jupp

 

[Wildcard]

Setz das look and feel ganz am Anfang (in main zB), dann sparst du dir erstens das updateComponentTree und zweitens löst das dein Problem.

 

[André Uhres]

Der DefaultButton reagiert auf Enter, unabhängig vom L&F.
Man könnte über einen FocusListener auch dafür sorgen,
dass der jeweils fokusierte Button zum DefaultButton wird.
Zum Beispiel bei einem OK-Button und einem CANCEL-Button:

       getRootPane().setDefaultButton(okButton);
        FocusAdapter resetDefaultButton = new FocusAdapter() {
                    @Override
			public void focusGained(FocusEvent e) {
                        JButton button = (JButton) e.getSource();
                        getRootPane().setDefaultButton(button);
                    }
                    @Override
			public void focusLost(FocusEvent e) {
                        getRootPane().setDefaultButton(okButton);
                    }
                };
        cancelButton.addFocusListener(resetDefaultButton);

 

[Wildcard]

@André
Das sollte man keinesfalls tun.
Bei GUIs sollte das Prinzip der geringsten Überraschung gelten.
Das bedeutet das Programm muss sich so verhalten wie die Programme an die der Nutzer gewöhnt ist.
Mit so einem Snippet kann man höchstens Linux (und Mac?) User ärgern. :wink:

 

[André Uhres]

Ich versteh nicht ganz, was überrascht dich denn so sehr?

 

[Wildcard]

Bei Gnome zB aktiviert Enter den Default Button und die Leertaste den fokusierten.
Als Entwickler sollte man sich an das L'n'F des Benutzers halten und das Verhalten nicht mutwillig verbiegen.
Dafür gibt's das System L'n'F schließlich.

 

[André Uhres]

So schlimm wirds nicht sein: unter Java 3 z.B. reagiert der fokusierte Button auch beim Java Look and Feel auf Enter. :wink:
Jedenfalls ist der Workaround im Sinne des Fragestellers.

 

[Wildcard]

So schlimm wirds nicht sein

offensichtlich schlimm genug um dafür einen Thread zu öffnen.

Jedenfalls ist der Workaround im Sinne des Fragestellers.

Warum den Workaround vorziehen? Damit wird's für einen Windows Nutzer intuitiver, dafür hat dann der Linux Nutzer das Problem.
Nimmt man das System Look and Feel macht man es beiden Recht.

unter Java 3 z.B. reagiert der fokusierte Button auch beim Java Look and Feel auf Enter.

Das Cross Platform Look and Feel ist ja bewusst auf allen Plattformen gleich und stimmt mit keiner Plattform überein.
Der Unterschied ist sofort zu erkennen insofern darf es sich auch anders verhalten. Wenn sie da was ändern... was soll's.
Das sich Cross Platform (Metal/Aqua) nicht durchsetzen konnte liegt neben der Optik genau daran. Es verhält sich eben anders. Mit den System Look and Feel kann man es besser machen, also soll man es bitte auch so tun.

 

[André Uhres]

Das was für den Fragesteller schlimm ist, das ist ja gerade das, was durch den Workaround behoben wird.
Welches L&F man schliesslich vorzieht ist wohl eher Geschmackssache.
Ausserdem wird auch ein Linux Nutzer kaum Schwierigkeiten damit haben, weil die Leertaste auch noch unterstützt wird und der DefaultButton jeweils optisch hervorgehoben wird.

 

[Wildcard]

1. Ich gehe davon aus, dass das Problem durch setzen des Look and Feels bereits behoben ist
2. Wenn man sich bewußt für das Cross Plattform L'n'F entscheidet (und nicht nur aus Unkenntniss über die Alternativen), dann sollte man das L'n'F trotzdem in Ruhe lassen -> Prinzip der geringsten Überraschung.

 

[André Uhres]

Es ist gut möglich dass das Problem durch das System L&F behoben ist, das will ich gar nicht bestreiten.
Ich will lediglich eine Alternative zeigen, für den Fall wo jemand ein anderes L&F wünscht.
Der Workaround darf auch keinesfalls als "verbiegen" angesehen werden: es ist eine legitime Alternative innerhalb des L&F.

 

[Wildcard]

Zeig mir ein Programm bei dem der Default Button springt?
Und das ist für dich nicht überraschend?

 

[André Uhres]

Wenn man den CANCEL-Button fokusiert, Enter drückt und dann feststellt, dass der OK-Button aktiviert wurde, das ist wohl schon etwas mehr als überraschend, u.U. sogar katastrophal, weil eventuell eine wichtige Datei gelöscht wurde :wink:

 

[Wildcard]

Wenn ich den Ok Button fokusiere, Enter drücke (im guten Gewissen das der Default Button ausgeführt wird der ursprünglich der cancel button war) und dann trotzdem der ok Button aktiviert wird, ist es nicht weniger dramatisch.

 

[André Uhres]

Jetzt hast du aber ein etwas verdrehtes Beispiel da angeführt.
Ich würde sagen, dass in einem solchen Fall der OK Button nicht fokusierbar sein sollte.

 

[Wildcard]

Warum?

 

[André Uhres]

Das ist so mein Gefühl, warum auch nicht?

 

[thE_29]

Ums generell auf was zu setzen, wie gehabt von den FAQ ist dies mit InputMap´s zu manipulieren..

javax.swing.plaf.InputMapUIResource res = (javax.swing.plaf.InputMapUIResource)javax.swing.UIManager.getDefaults().get("Button.focusInputMap");
    javax.swing.KeyStroke enterPressed = javax.swing.KeyStroke.getKeyStroke(java.awt.event.KeyEvent.VK_ENTER,0,false);
    javax.swing.KeyStroke enterReleased = javax.swing.KeyStroke.getKeyStroke(java.awt.event.KeyEvent.VK_ENTER,0,true);
    res.put(enterPressed,"pressed");
    res.put(enterReleased,"released");

Schon funktioniert es via Leertaste und Enter auf jedem Button!

Ich selbst finde das mit dem Defaultbutton auch selten blöd...

Es wird ein 2t Button fokusiert und wenn man enter drückt wird der defaultbutton aufgerufen...

Aber wenn man die InputMap so manipuliert wie oben, reagiert der fokusierte Button zuerst aufs Enter und es würde meines Erachtens passen!