Keylistener, Taste überprüfen

[Djinndrache]

Hallo,

ich möchte gerne prüfen, ob STRG + ENTER gedrückt ist.


Hier ein kleiner Codeschnipsel, mit dem ich ENTER überprüfe:

		inputAnswer.addKeyListener(new KeyListener() {
			public void keyPressed(KeyEvent e) {
	
			}

			public void keyReleased(KeyEvent e) {
				if (e.getKeyCode() == KeyEvent.VK_ENTER) {
					System.out.println("test");
				}
			}

			public void keyTyped(KeyEvent e) {
			}
		});

Das klappt auch soweit. Nur krieg ich es nicht hin, gleichzeitig auch noch auf STRG zu prüfen. Wenn ich einfach mit einem logischen && die STRG-Taste prüfe passiert nichts - geht nicht.


Wäre dankbar für Hilfe

 

[Niki]

Probiers mal mit isControlDown

 

[Djinndrache]

Probiers mal mit isControlDown

Wunderbar, danke!

 

[Wildcard]

Du solltest wo immer möglich keine KeyListener, sondern KeyBindings verwenden.
http://java.sun.com/docs/books/tutorial/uiswing/misc/keybinding.html

 

[Djinndrache]

Du solltest wo immer möglich keine KeyListener, sondern KeyBindings verwenden.
http://java.sun.com/docs/books/tutorial/uiswing/misc/keybinding.html

Wieso? Solange es mit einem KeyListener ebenso funktioniert ist das doch egal, oder nicht?

 

[Wildcard]

Mit Bindings kapselt du alles objektorientiert in wiederverwendbaren Actions, ausserdem bist du nicht auf die Position des Eingabe Fokus angewiesen.

 

[FArt]

Du solltest wo immer möglich keine KeyListener, sondern KeyBindings verwenden.
http://java.sun.com/docs/books/tutorial/uiswing/misc/keybinding.html

Wieso? Solange es mit einem KeyListener ebenso funktioniert ist das doch egal, oder nicht?

Du solltest immer ein paar Bierchen trinken, und kein Methanol.

Wieso? Schädelt doch auch ganz gut.

:autsch:

 

[SlaterB]

ein KeyListener ist in gleicher Weise wiederverwendbar
und ob man den Focus haben will oder nicht ist doch eine Sache, über die man nachdenken darf

 

[Wildcard]

ein KeyListener ist in gleicher Weise wiederverwendbar
und ob man den Focus haben will oder nicht ist doch eine Sache, über die man nachdenken darf

Anders gefragt: welchen Vorteil siehst du im KeyListener?

 

[byte]

Ich würde auch immer Actions und Key Bindings (bzw. Mnemonics) bevorzugen.

An alternative to key bindings is using key listeners. Key listeners have their place as a low-level interface to keyboard input, but for responding to individual keys key bindings are more appropriate and tend to result in more easily maintained code. Key listeners are also difficult if the key binding is to be active when the component doesn't have focus. Some of the advantages of key bindings are they're somewhat self documenting, take the containment hierarchy into account, encourage reusable chunks of code (Action objects), and allow actions to be easily removed, customized, or shared. Also, they make it easy to change the key to which an action is bound. Another advantage of Actions is that they have an enabled state which provides an easy way to disable the action without having to track which component it is attached to.

 

[SlaterB]

Anders gefragt: welchen Vorteil siehst du im KeyListener?

Vorteil gegenüber was?
gegenüber nix: man kann auf Keys reagieren

gegenüber Bindings:
- natürliches Verhalten, nur Events bei Focus, bei TextFeldern von Sondertasten abgesehen nur Events wenn Buchstabe auch im Textfeld erscheinen würde
- analoges verständliches Konzept zu MouseListener(!)/ ActionListener/ sonstige Listener,
- einfache Bearbeitung von Buchstabengruppen/ gesamte Tastatureingaben/ Modifern

 

[Wildcard]

Bei KeyBindings bestimmst du selbst ob die Komponente fokusiert sein muss, irgendeine Komponente im gleichen Fenster, oder die Komponente ein Parent der fokussierten Komponente sein muss.
Man hat also mehr Funktionalität und Flexibilität während der Code IMO besser lesbar ist als bei KeyListenern.
Daher auch die Empfehlung von Sun selbst sie wo immer möglich den KeyListenern vorzuziehen.

Sträubst du dich jetzt dagegen, weil ich es gesagt habe, oder weil du es bisher anders machst?
Denn einen objektiven Grund gibt es eigentlich nicht :bahnhof:

 

[SlaterB]

> Bei KeyBindings bestimmst du selbst ob die Komponente fokusiert sein muss [..]

das ist ja auch eine tolle Sache, aber wenn man zwei Strings mit equals vergleichen oder mit Comparable sortieren kann,
schreibt man ja auch nicht einen riesigen Comparator-Komplex

> Man hat also mehr Funktionalität und Flexibilität während der Code IMO besser lesbar ist als bei KeyListenern.

zur Funktionaltät nochmal das gleiche Spiel: Vergleich BigInteger vs int

Lesbarkeit kann natürlich jeder sehen wie es ist,
die Analogie zu Mouse- und sonstigen Listenern habe ich ja extra als Vorteil aufgezählt, da dürfte meine Sicht klar sein

> Daher auch die Empfehlung von Sun selbst sie wo immer möglich den KeyListenern vorzuziehen.

tja, aber deprecated sind die KeyListener aber nun noch lange nicht,

hier
http://java.sun.com/docs/books/tutorial/uiswing/events/keylistener.html
steht z.B.
> Note: To define special reactions to particular keys, use key bindings instead of a key listener. For further information, see How to Use Key Bindings.

und da muss ich auch zustimmem: für eine bestimmte Taste(n-Kombination) hat das KeyBinding-System mit Mapping Key -> Aktion natürlich einen ganz besonderen Reiz


> Sträubst du dich jetzt dagegen, weil ich es gesagt habe, oder weil du es bisher anders machst?

zunächst mal sträube ich mich immer gegen unbegründete Aussagen 'so ist es schlecht',
noch schlimmer mit Verweisen 'hier wird es so empfohlen', ohne einen echten Grund anzugeben,
das klingt immer bös von oben herab, da widerspreche ich schon aus Prinzip

ich selber verwende beides nicht

> Denn einen objektiven Grund gibt es eigentlich nicht

solange es keinen objektiven Grund für KeyBinding gibt, wäre das ja theoretisch kein Problem,
wobei ich meine, drei objektive aufgezählt zu haben

 

[byte]

- wobei ich meine, drei objektive aufgezählt zu haben

Naja, Punkt 1 und 3 sind falsch und Punkt 2 ("KeyListener analog zu MouseListener"), warum ist das in Deinen Augen ein Vorteil? Weil Newbies dann schneller durchblicken? :bahnhof:

 

[tfa]

zunächst mal sträube ich mich immer gegen unbegründete Aussagen 'so ist es schlecht',
noch schlimmer mit Verweisen 'hier wird es so empfohlen', ohne einen echten Grund anzugeben,
das klingt immer bös von oben herab, da widerspreche ich schon aus Prinzip

Die Begründung warum bzw. wann Bindings statt Listener steht doch in dem von Wildcard angegebenen Link. Man muss es einfach nur lesen. Im Übrigen finde ich solche Ratschläge absolut nicht "von oben herab" sondern ziemlich wertvoll, wenn man seine Kenntnisse weiter entwickeln will. Man möchte doch z.B. nicht ewig mit Singletons als Globale-Variable-Ersatz oder Access-"Datenbanken" herumkrepeln, oder? Warum sollten Newbies es nicht gleich richtig machen?

 

[SlaterB]

Naja, Punkt 1 und 3 sind falsch

inwiefern?

und Punkt 2 ("KeyListener analog zu MouseListener"), warum ist das in Deinen Augen ein Vorteil? Weil Newbies dann schneller durchblicken? :bahnhof:

Listener ist ein zentrales Konzept in Swing, einer der grundlegendsten Fachbegriffe

'Writing Event Listeners' ist z.B. einer der 10 Hauptpunkte im Swing-Tutorial,
während KeyBindings unter 'Using Other Swing Features' versteckt ist

dass man ein Event bekommt 'Buchstabe x wurde gedrückt' ist genau das,
was man in so einer Situation als einfaches Event haben möchte,
ist 'der natürliche Weg'

----------

Die Begründung warum bzw. wann Bindings statt Listener steht doch in dem von Wildcard angegebenen Link. Man muss es einfach nur lesen.

hmm, stimmt,
dass dort im Detail der Vergleich zu KeyListener steht hatte ich nicht bedacht

siehe auch Nachfrage von Djinndrache
> Wieso?

+ Antwort

> Mit Bindings kapselt du alles objektorientiert in wiederverwendbaren Actions, ausserdem bist du nicht auf die Position des Eingabe Fokus angewiesen.

auf diesen Satz als einzige Begründung hatte ich geantwortet, nicht auf den angegebenen Link

----------

und nicht dass es falsch verstanden wird:
ich sage nicht, dass eines der beiden Konzepte besser als das andere ist,
aber wenn der arme KeyListener ohne Not niedergemacht wird, dann verteidige ich ihn


--------

Im Übrigen finde ich solche Ratschläge absolut nicht "von oben herab" sondern ziemlich wertvoll, wenn man seine Kenntnisse weiter entwickeln will. Man möchte doch z.B. nicht ewig mit Singletons als Globale-Variable-Ersatz oder Access-"Datenbanken" herumkrepeln, oder? Warum sollten Newbies es nicht gleich richtig machen?

das ist wieder eine Ansichtssache,
wenn jemand mit Mühe eine Liste per for-Schleife durchläuft,
dann finde ich einen dezenten Hinweis auf Collections.contains() hilfreich,
aber es hat auch seinen Sinn, das mal selber gemacht zu haben,

und 'das Rad neu erfinden/ eine Liste manuell zu durchlaufen ist wenn möglich zu vermeiden, verwende [High Level API xy]'
fände ich wieder sehr unangebracht, besonders wenns noch sowas exotisches wie JCommons ist

 

[byte]

> wenn jemand mit Mühe eine Liste per for-Schleife durchläuft,
> dann finde ich einen dezenten Hinweis auf Collections.contains() hilfreich,
> aber es hat auch seinen Sinn, das mal selber gemacht zu haben,

Jo. Aber wenn er nicht weiss, wie es "richtig" geht, dann wird er es auch in Zukunft nicht schön machen. Es ist doch auch der Sinn dieses Forums, Verbesserungsvorschläge zu machen. ???:L

 

[SlaterB]

wieso der Kopf-kratz-Smilie, ich stimme doch zu?

 

[byte]

Ich mag den, weil der so dämlich drein glotzt! :lol:

 

[Djinndrache]

Okay, dann mal konkret für meinen Fall:

Wenn ich im Textfeld Fokus habe soll ENTER ein Zeilenumbruch sein (normal). STRG+Enter soll das Formular allerdings "Absenden", aber auch nur im Fokus des Textfelds.

Jetzt ihr Profis: Machen in diesem Fall Key Bindings mehr Sinn als mein toller Listener?

 

[SlaterB]

da du nur auf eine einzelne Taste reagierst ist KeyBindings die logische Wahl

 

[Djinndrache]

da du nur auf eine einzelne Taste reagierst ist KeyBindings die logische Wahl

Gibts ein besseres Tutorial für KeyBindings, als das komische vorhin? Das ist mir zu hoch

Ein Beispielcode würde mir reichen, daraus kann man bestimmt entnehmen wie das geht.