Input/Output KeyState auslesen

[jf]

Hello, wie ermittelt man bei Java den KeyState?
Ich möchte während der Abarbeitung eines Ereignisses (z. B. Bewegung eines Fensters) prüfen, ob währenddessen eine bestimmte Taste gedrückt wurde. Der Status der Taste sollte synchron mit dem Ereignis sein (also den Zustand liefern, welchen die Taste während des Auftretens des Ereignisses hatte - und nicht den Zustand, während der Abarbeitung des Ereignisses).

 

[Crian]

Es klingt mir danach, als suchst du nach dem Schlüsselwort

KeyListener

.

 

[irgendjemand]

sowas löst man wohl am besten mit nem Listener ... weil in nem seperaten thread in nem loop etwas zu pollen ist sicher nicht die beste lösung

 

[jf]

Wer redet denn von Polling? - Bei der Programmierung unter Windows in anderen Sprachen würde man an dieser Stelle einfach die API GeyKeyState verwenden.
Ein KeyListener ist hier meines Erachtens nach ungünstig, da er selbst separat das Key-Ereignis behandelt und somit keine Verbindung zum Ereingis "Fenster-Bewegung" besteht:
Ich müsste bei KeyDown einer bestimmten Taste eine Member-Variable auf true setzen und bei KeyUp wieder auf false. Wenn dann beim Bewegen des Fensters die Variable true ist, weiß ich, dass die Taste gedrückt wurde. - Ich halte das Abfragen des KeyState im "Fenster-Bewegen"-Ereignis auf jedenfall für den besseren Programmierstil. Wenn es so etwas unter Java nicht gibt, dann wäre das wirklich bedauerlich...

 

[Zertos]

In Java kannst du die KeyStroke Klasse verwenden.

 

[irgendjemand]

was ich mit polling meinte war das selbstständig anfragen ob eine taste gedrückt wurde ...

in OOP *und speziell in JAVA* macht man es genau so das man einen listener aufsetzt ... und in dessen keyPressed und keyRealeased methoden ein flag toggled ... alles andere wäre nicht im sinne von OOP und würde eine unterwanderung von java's eventhandling bedeuten ...

und ist es denn wirklich so ein großer unterschied ob du nun in dem moment wo das mouseEvent kommt *welches ja nun mal das verschieben des fensters auslöust* manuell die tastatur fragst ob eine taste gedrückt ist ... oder einfach ein flag prüfst welches vor von nem keylistener getoggled wurde ? ... in meinen augen ist das flag hier die deutlich saubere variante ...

 

[jf]

was ich mit polling meinte war das selbstständig anfragen ob eine taste gedrückt wurde ...

in OOP *und speziell in JAVA* macht man es genau so das man einen listener aufsetzt ... und in dessen keyPressed und keyRealeased methoden ein flag toggled ... alles andere wäre nicht im sinne von OOP und würde eine unterwanderung von java's eventhandling bedeuten ...

und ist es denn wirklich so ein großer unterschied ob du nun in dem moment wo das mouseEvent kommt *welches ja nun mal das verschieben des fensters auslöust* manuell die tastatur fragst ob eine taste gedrückt ist ... oder einfach ein flag prüfst welches vor von nem keylistener getoggled wurde ? ... in meinen augen ist das flag hier die deutlich saubere variante ...

Nein, meiner Ansicht nach ist es dies definitiv nicht!

Ich möchte den KeyState in dem Moment, wo die Maus-Nachricht generiert wurde - die Abarbeitung der Nachricht kann unter Umständen (bei hoher CPU-Last) später sein - zu einem Zeitpunkt, wo die Taste schon wieder losgelassen wurde. Hier findest du einen Artikel über das Problem.

Außerdem wäre das Flag bezüglich der Klasse eine globale Variable. - Und das macht man nur, wenn es wirklich nicht anders geht. Was aber bei Java durchaus der Fall sein könnte... - Ich bin nämlich mit KeyStroke nicht weiter gekommen: damit kann man nur eine InputMap konfigurieren, oder?
Wie frage ich damit denn den Status einer Taste ab?

 

[Michael...]

Bei Events, die von InputEvent erben (KeyEvent, MouseEvent) kann man abfragen, ob beim Auslösen des Events bestimmte "Meta" Tasten gedrückt waren. Bei anderen Events oder Tasten muss man das mittels Flag und KeyListener bzw. Key Bindings wohl selbst implementieren - zumindest wüsste ich in Java keine andere Möglichkeit.

 

[jf]

Bei Events, die von InputEvent erben (KeyEvent, MouseEvent) kann man abfragen, ob beim Auslösen des Events bestimmte "Meta" Tasten gedrückt waren.

isControlDown() ist genau das was ich brauche - nur geht es bei mir leider um folgende Events:
HierarchyEvent (bei ancestorMoved)
ComponentEvent (bei componentMoved)

Bei anderen Events oder Tasten muss man das mittels Flag und KeyListener bzw. Key Bindings wohl selbst implementieren - zumindest wüsste ich in Java keine andere Möglichkeit.

Das habe ich zwischenzeitlich schon begonnen zu implementieren, was aber äußerst hässlich ist:
ich muss den KeyListener wohl zu allen Komponenten auf meinen Fenstern hinzufügen... ;(

Die Situation ist folgende: der Nutzer drückt Strg und klickt dann in die Titelleiste eines Fensters.
Wenn der dann die Maus bewegt, bewegt sich auch das Fenster - und in diesem Fall zünden dann entweder componentMoved oder ancestorMoved Ereignisse, in welchen ich die Tasten-Info benötige.

Evtl. sollte ich besser einen Listener für die Maus den jeweiligen Fenstern hinzufügen. Und über dessen isConrolDown() den Flag setzten. - Erkennt ein MouseListener NC-Ereignisse (Non-Client)?


EDIT:
Mit einem MouseMotionListener bekomme ich jedenfalls keine NC-Ereignisse... ;(
Was ist überhaupt der Unterschied zwischen einem MouseMotion- und einem MouseMoveListener? ???:L
Gibt es einen Listener für Maus-Ereignisse in der Titelleiste eines Fensters?

 

[irgendjemand]

Ich möchte den KeyState in dem Moment, wo die Maus-Nachricht generiert wurde - die Abarbeitung der Nachricht kann unter Umständen (bei hoher CPU-Last) später sein - zu einem Zeitpunkt, wo die Taste schon wieder losgelassen wurde.

du hast OOP scheinbar immer noch nicht verstanden ... ich weis zwar nicht genau was du jetzt mit der maus machen willst ... aber

wenn du eine taste drückst ... wird dies vom EDT aufgefangen und an alle registrierten listener weitergereicht ... steht jetzt in irgend einem listener das ein flag geändert werden soll wird dies auch ausgeführt ...

wenn du jetzt mit der maus irgend ein event erzeugst *klick oder movement* dann wird dies auch vom EDT gefangen ... aber erst nach dem dieser mit der verarbeitung des tasten-events fertig ist ...

ergo : der EDT nimmt das maus-event erst an nach dem alle key-listener über das betätigen einer taste informiert werden ...

natürlich auch genau so umgekehrt ...

wie du jetzt auf den pfad kommst das das maus-event erst abgearbeitet wird nach dem die taste wieder losgelassen wurde weis ich nicht ... weil um das zu erreich muss die taste schon bewusst vor dem maus event gelöst werden ... gleiches gilt für den fall "wenn taste NOCH nicht gedrückt"

ich glaub dir fehlt hier einiges an grundwissen über den EDT ...

oder bist du einer dieser profis die wirklich 4 tasten + maus GLEICHZEITIG ... auf die nanosekunde genau ... betätigen ? glaub mir ... das ist garnicht möglich ...

also : taste drücken und gedrückt halten ... dann maus-event produzieren ... und dann *wenn logik zulässt* meinet wegen die taste loslassen ...


das was du willst ... manuell in den EDT eingreifen und eine eigene abfrage gegen den key-input lostreten ... ist sehr schlechtes design ...


btw : natürlich muss ein flag irgendwo "global" sein ... ansonsten ist es verschwunden so bald der block zu ende ist ...
wobei man natürlich trotzdem getter und setter verwenden sollte anstatt public ...

 

[Michael...]

Das habe ich zwischenzeitlich schon begonnen zu implementieren, was aber äußerst hässlich ist:
ich muss den KeyListener wohl zu allen Komponenten auf meinen Fenstern hinzufügen... ;(

Ich würde sowas dann eher mit Key Bindings umsetzen. Das kann man so implementieren, dass es ausreicht, dass die Komponente im fokusierten Fenster liegt.

Was ist überhaupt der Unterschied zwischen einem MouseMotion- und einem MouseMoveListener? ???:L

Meinst wohl MouseListener und MouseMotionListener. Erster reagiert auf alle Arten von Klicks und den Maus"eintritt" und "austritt". Letzerer auf eine bewegte oder gezogene Maus über der Komponente (vgl. API Doku)

Gibt es einen Listener für Maus-Ereignisse in der Titelleiste eines Fensters?

Wüsste nicht, die Titelleiste eines Fensters wird von Betriebsystem verantwortet. Man könnte sich eine eigene basteln und das Fenster undekoriert machen.

 

[Michael...]

Die Situation ist folgende: der Nutzer drückt Strg und klickt dann in die Titelleiste eines Fensters.
Wenn der dann die Maus bewegt, bewegt sich auch das Fenster - und in diesem Fall zünden dann entweder componentMoved oder ancestorMoved Ereignisse, in welchen ich die Tasten-Info benötige.

Das könnte möglicherweise schwierig werden. Das Fenster ist wird ja durch das Betriebssytem "gestellt", wenn man es mit der Maus am an der Titelleiste packt, reagieren z.B. die KeyListener nicht mehr. (Kannst ja mal versuchen das Browserfenster zu verschieben und gleichzeitig hier zu posten). Da müsste man sich evtl. mit einer selbst gebastelten Titelleiste behelfen.

 

[jf]

Ich würde sowas dann eher mit Key Bindings umsetzen. Das kann man so implementieren, dass es ausreicht, dass die Komponente im fokusierten Fenster liegt.

Ok, prima. Wie macht man das?

Meinst wohl MouseListener und MouseMotionListener. Erster reagiert auf alle Arten von Klicks und den Maus"eintritt" und "austritt". Letzerer auf eine bewegte oder gezogene Maus über der Komponente (vgl. API Doku)

Nein, ich meinte schon MouseMoveListener... Ein solcher wird in diesem Beispiel verwendet:
JButtonObject.addMouseMoveListener(new MouseMoveListener() { ...
- ein solcher wurde mir aber vom Eclipse-Intellisense nicht vorgeschlagen, was mich halt verwundert hat.
(wahrscheinlich liegt es aber einfach nur daran, dass dies ein SWT-Beispiel ist...)

Wüsste nicht, die Titelleiste eines Fensters wird von Betriebsystem verantwortet. Man könnte sich eine eigene basteln und das Fenster undekoriert machen.

Ok, ich verstehe. Für die NC-Bereich gibt es eigene Nachrichten, welchen ein "NC" vorgestellt ist (z. B. WM_MOUSEMOVE vs. WM_NCMOUSEMOVE). Es hätte ja sein können, die JVM verarbeitet auch diese.
Wenn es mit dem Key Binding zu lösen ist, dann wäre so etwas ja nicht nötig.


@irgendjemand:
OOP ist mir schon klar, nur komme ich aus einer anderen Ecke der Programmierung (siehe verlinkter Artikel) - dieser andere Hintergrund lässt mich natürlich schnell falsche Schlussfolgerungen ziehen.

 

[jf]

Das könnte möglicherweise schwierig werden. Das Fenster ist wird ja durch das Betriebssytem "gestellt", wenn man es mit der Maus am an der Titelleiste packt, reagieren z.B. die KeyListener nicht mehr. (Kannst ja mal versuchen das Browserfenster zu verschieben und gleichzeitig hier zu posten). Da müsste man sich evtl. mit einer selbst gebastelten Titelleiste behelfen.

Dieses Verhalten ist logisch, wenn die KeyListener die NC-Nachrichten nicht erhalten.
Bei der Progammierung mit der Windows-API ist das natürlich alles kein Problem.

Aber es wäre auch nicht der Rede wert, wenn man unter ancestor- bzw. componentMoved den Tasten-Status direkt auslesen könnte, so wie es mit der Windows-API GetKeyState möglich ist.

@irgendjemand:
Wenn die javasche OOP nun wirklich soooo toll ist, dann müsste es hierfür doch auch eine Lösung geben... Hast du eine Idee? ???:L

 

[irgendjemand]

1)
das was du gepostet hast ist SWT ... und ist ein framework für java ... wenn dort eigene Listener mitgebracht werden ist das schön und gut ... heißt aber nicht das diese mit SE dabei sind *wie eben MouseMoveListener ... den gibt es so nicht in java sondern ist eine klasse der SWT-lib ...

2)
wenn du beim klick auf die fenster-leiste mit java prüfen willst ob eine taste gedrückt ist wird das so vermutlich garnichts ... denn die fensterleiste kommt vom OS *auch unter unix* und liegt damit gar nicht mehr im bereich irgendwelcher listener von java ...

hier hätte ich zwei lösungen :

1)
window nutzen *undecorated* und selbst ne leiste basteln *dürfte aufwändig werden*
2)
das hier nutzen : Java – Global (low level) Keyboard / Mouse Hook – JNI kSquared.de – Blog
das ist ein globaler mouse/keyboard hook für windows *weis net von wem das original unix-zeug ist was dort angesprochen wird* ... mit dem du dann trotzdem zumindest auf key-events warten könntest ... was aber vorraussetzt das du mit dem event-system und einem flag arbeitest ... dierekt das OS nach gedrückten tasten fragen geht auch damit nicht

[EDIT]

Wenn die javasche OOP nun wirklich soooo toll ist, dann müsste es hierfür doch auch eine Lösung geben... Hast du eine Idee?

ja ... wie ich bereits mehrfach sagte : einen keylistener implementieren und ein globales flag togglen ... und dann dieses an benötiger stelle abfragen ...

der ganze kram den du hier versuchst mit bewusst das OS nach gedrückten tasten fragen wird wohl nur mit JNI dierekt möglich sein[/EDIT]

 

[jf]

1) das was du gepostet hast ist SWT

Ja, das hatte ich dann auch bemerkt.

2) wenn du beim klick auf die fenster-leiste mit java prüfen willst ob eine taste gedrückt ist wird das so vermutlich garnichts ... denn die fensterleiste kommt vom OS *auch unter unix* und liegt damit gar nicht mehr im bereich irgendwelcher listener von java ...

Genau das ist ja eines der Probleme...

1) window nutzen *undecorated* und selbst ne leiste basteln *dürfte aufwändig werden*

Ja, das wöllte ich vermeiden - es würde sicherlich recht umständlich, hier das Native Look&Feel stets korrekt darzustellen.

2) das hier nutzen : Java – Global (low level) Keyboard / Mouse Hook – JNI kSquared.de – Blog
das ist ein globaler mouse/keyboard hook für windows *weis net von wem das original unix-zeug ist was dort angesprochen wird* ... mit dem du dann trotzdem zumindest auf key-events warten könntest ... was aber vorraussetzt das du mit dem event-system und einem flag arbeitest ... dierekt das OS nach gedrückten tasten fragen geht auch damit nicht

Hmm. Ich dachte bisher, dass man mit JNI auch Windows-dlls ansprechen kann.
Wenn das stimmt, dann könnte man doch einfach eine dll erstellen, welche GetKeyState oder GetAsyncKeyState aufruft...
- Aber eigentlich wollte ich auf diesen Firlefanz verzichten. :noe:

ja ... wie ich bereits mehrfach sagte : einen keylistener implementieren und ein globales flag togglen ... und dann dieses an benötiger stelle abfragen ...

Das tue ich ja bereits - aber es funktioniert leider nicht...
Muss ich den Listener wirklich zu jeder Komponente in meinen Fenstern hinzufügen???
Wie geht das mit dem globalen Key-Binding? - Könnte das eine Alternative sein?

der ganze kram den du hier versuchst mit bewusst das OS nach gedrückten tasten fragen wird wohl nur mit JNI dierekt möglich sein

Mist.

 

[Michael...]

Hier mal eine Key Binding Demo, aber wie Du feststellen wirst, funktioniert das ganze beim Schieben des Fensters nicht mehr. Hier wirst Du vermutlich um eine Verwendung von native Libs nicht herumkommen.

import java.awt.GridLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ComponentEvent;
import java.awt.event.ComponentListener;
import java.awt.event.KeyEvent;
import java.awt.event.MouseEvent;
import java.awt.event.MouseMotionListener;

import javax.swing.AbstractAction;
import javax.swing.ActionMap;
import javax.swing.InputMap;
import javax.swing.JComponent;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.JTextField;
import javax.swing.KeyStroke;


public class FrameDragCTRLDemo extends JPanel implements ComponentListener {
	
	public static void main(String[] s) {
		FrameDragCTRLDemo fdcd = new FrameDragCTRLDemo();
		
		JFrame frame = new JFrame();
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.setBounds(0, 0, 250, 150);
		frame.add(fdcd);
		frame.setVisible(true);
		
		frame.addComponentListener(fdcd);
	}
	
	
	private boolean controlIsDown;
	
	private JLabel controlLabel, mouseLabel, compLabel;
	
	public FrameDragCTRLDemo() {
		
		this.setLayout(new GridLayout(0,1));
		this.add(controlLabel = new JLabel("control"));
		this.add(mouseLabel = new JLabel("mouse"));
		this.add(compLabel = new JLabel("control"));
		JTextField field = new JTextField();
		this.add(field);
		
		InputMap input = this.getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW);
		input.put(KeyStroke.getKeyStroke(KeyEvent.VK_CONTROL, KeyEvent.CTRL_DOWN_MASK, false), "ctrl_down");
		input.put(KeyStroke.getKeyStroke(KeyEvent.VK_CONTROL, 0, true), "ctrl_up");
		ActionMap action = this.getActionMap();
		action.put("ctrl_down", new AbstractAction() {
			public void actionPerformed(ActionEvent e) {
				controlLabel.setText("   control is down");
				controlIsDown = true;
			}
		});
		action.put("ctrl_up", new AbstractAction() {
			public void actionPerformed(ActionEvent e) {
				controlLabel.setText("   control is up");
				controlIsDown = false;
			}
		});
		this.addMouseMotionListener(new MouseMotionListener() {
			public void mouseDragged(MouseEvent e) {
				if (controlIsDown)
					mouseLabel.setText("   mouse dragged and control is down");
				else
					mouseLabel.setText("   mouse dragged and control is up");
			}

			public void mouseMoved(MouseEvent e) {
				if (controlIsDown)
					mouseLabel.setText("   mouse moved and control is down");
				else
					mouseLabel.setText("   mouse moved and control is up");
			}
		});
	}

	public void componentMoved(ComponentEvent e) {
		if (controlIsDown)
			compLabel.setText("   moved and control is down");
		else
			compLabel.setText("   moved and control is up");
	}
	
	public void componentResized(ComponentEvent e) {}
	public void componentShown(ComponentEvent e) {}
	public void componentHidden(ComponentEvent e) {}
}

 

[irgendjemand]

das dierekte ansprechen bereits vorhandener LIBs *win : DLL , unix : SO , mac : weis ich erlich gesagt nicht* nennt sich JNA ...
das unterscheidet sich ETWAS von JNI

JNI
du schreibst eine klasse in der es "native" methoden gibt
du compilest diese klasse
du führst "javah" aus um aus der compileten klasse ein C header-file zu erzeugen
du schreibst eine LIB die dieses header-file sowie die JNI-header und JNI-OS-header *es gibt verschiedene für win und unix* included und implementiert ...
dafür sind aber C kenntnisse notwendig

*das ganze geht auch mit C++ ... wobei es ja so ganz grob nur den unterschied gibt das C++ OOP ist ... und C nicht *so hat man mir das mal erklärt ... wie viel wahres dran is weis ich nich**


JNA
du schreibst eine klasse die mit hilfe spezieller helper klassen eine zur runtime geladene LIB dierekt verwenden kann
dafür ist die genaue kenntnis der LIB notwendig ... welche sich nur durch source aneignen lässt ... was also unter windows bei nicht-open-source libs quasi unmöglich ist

das ganze selbst nachbauen ... hmm wird schwer ... aber du könntest deinem programm einen komplett eigenen look verpassen ...

das diese globalen key-events angeht : soweit ich weis kann man jeder swing-component einen listener anhängen ... müsste aber auch dierekt auf das JFrame .. bzw dessen contentPane möglich sein ...
versucht hab ich sowas selbst noch nciht weil nicht gebraucht ... aber jeder component einen listener adden brauchst du nicht ... lediglich dem "höchstens" container *was ja dann das contentPane sein dürfte*

[EDIT]das beispiel von micha zeigt es : dem JFrame ein JPanel als "obersten" container adden und dann auf diesen den KeyListener binden ...
das das ganze dann aber plötzlich nicht mehr funktioniert wenn der focus vom JPanel auf z.b. eine JTextArea wandert ... liegt halt daran das nur das objekt events gefeuert werden was halt gerade den focus hat[/edit]


ansonsten versteh ich aber so langsam das problem selbst : du willst auf key-events prüfen obwohl du außerhalb des java-event-tress bist *was ja schon auf die fenster-leiste zutrifft* ... und ob das noch mit SE mitteln möglich ist ... na ich weis nicht so recht ... wie gesagt : ohne JNI/JNA wird das sicher nichts ... und eine JNI möglichkeit hab ich dir schon gelinkt

 

[jf]

@Michael...:
Vielen Dank für dein Key-Binding-Beispiel - es hat mir bei der Implementierung von anwendungsweiten Hotkeys sehr geholfen!

Ich habe da nur noch ein Problem bei einem JTabbedPane und einer JList:
Beim JTabbedPane will ich die Nach-Links- und Nach-Rechts-Tastenschläge überschreiben. (mit dem Ziel, das die Tabs zwar auch immer noch gewechselt werden, aber wenn man am Ende angelengt ist, dass dann nicht wieder zum Anfang gesprungen wird)
In der JList möchte ich das Gleich erreichen: Navigation durch die Tabs (jedes Tab hat eine JList).

Ich habe dazu auch bereits das hier ausprobiert. - Es funktioniert aber leider nicht!
=> Ist das gewünschte nur mit KeyListenern möglich?

Weiterhin zeigt dein Beispiel auch recht gut das Problem mit dem Auslesen der KeyEvents, während ein Fenster bewegt wird.

@irgendjemand:

das dierekte ansprechen bereits vorhandener LIBs *win : DLL , unix : SO , mac : weis ich erlich gesagt nicht* nennt sich JNA ...
das unterscheidet sich ETWAS von JNI

Ok, gut zu wissen!

JNI
du schreibst eine klasse in der es "native" methoden gibt
du compilest diese klasse
du führst "javah" aus um aus der compileten klasse ein C header-file zu erzeugen
du schreibst eine LIB die dieses header-file sowie die JNI-header und JNI-OS-header *es gibt verschiedene für win und unix* included und implementiert ...
dafür sind aber C kenntnisse notwendig

Hmm. Dies klingt recht umständlich...
Ich halte JNA rein von deiner Beschreibung her für einfacher. - Kann man das so sehen?

*das ganze geht auch mit C++ ... wobei es ja so ganz grob nur den unterschied gibt das C++ OOP ist ... und C nicht *so hat man mir das mal erklärt ... wie viel wahres dran is weis ich nich**

So ist es mir auch geläufig.
Aber sollte es nicht egal sein, in welcher Sprache die dll geschrieben wurde?

JNA
du schreibst eine klasse die mit hilfe spezieller helper klassen eine zur runtime geladene LIB dierekt verwenden kann
dafür ist die genaue kenntnis der LIB notwendig ... welche sich nur durch source aneignen lässt ... was also unter windows bei nicht-open-source libs quasi unmöglich ist

Die Windows APIs sind verhältnismäßig gut dokumentiert (wenn Mircosoft nicht wieder mal einen Fehler in der Doku eingebaut hat...). Wenn die dll eine Funktion exportiert, dann braucht man diese doch "nur" aufrufen und den Rückgabewert in Empfang zu nehmen. - Eine genaue Kenntnis, wie die Funktion intern arbeitet, ist eigentlich irrelevant. Kennst du ein gutes Tutorial für JNA?

das ganze selbst nachbauen ... hmm wird schwer ... aber du könntest deinem programm einen komplett eigenen look verpassen ...

Das ist leider ein No-Go für mich: ich akzeptiere nur das Native Look and Feel.
Ich habe schon ein Problem damit, dass die InternalFrames bei Swing nicht haargenau den MDI-Childs eines nativen Windows-Fensters entsprechen...

das diese globalen key-events angeht : soweit ich weis kann man jeder swing-component einen listener anhängen ... müsste aber auch dierekt auf das JFrame .. bzw dessen contentPane möglich sein ...
versucht hab ich sowas selbst noch nciht weil nicht gebraucht ... aber jeder component einen listener adden brauchst du nicht ... lediglich dem "höchstens" container *was ja dann das contentPane sein dürfte*

Gut, das hatte ich probiert - aber evtl. hatte ein Textfeld den Fokus.
Ich habe es für die Hotkeys ja nun mit KeyBinding gelöst. Aber warum gibt es überhaupt diese zwei unterschiedlichen Konzepte: KeyBinding und KeyListener?

[EDIT]liegt halt daran das nur das objekt events gefeuert werden was halt gerade den focus hat[/edit]

Das habe ich jetzt nicht ganz verstanden... Meinst du: Die Nachrichten werden an die Componente mit dem Fokus geleitet, wenn dieses diese Nachrichten selber nicht verarbeitet, dann reicht es die Nachrichten an den Parent weiter - ansonsten aber nicht?

ansonsten versteh ich aber so langsam das problem selbst : du willst auf key-events prüfen obwohl du außerhalb des java-event-tress bist *was ja schon auf die fenster-leiste zutrifft* ... und ob das noch mit SE mitteln möglich ist ... na ich weis nicht so recht ... wie gesagt : ohne JNI/JNA wird das sicher nichts ... und eine JNI möglichkeit hab ich dir schon gelinkt

Ja, so ist es: ich möchte JDialog erweitern und dieser Klasse dabei ein wenig Mac-Funktionalität beibringen: in diesem Video ist bei Minute 4:24 ein Dialog zu sehen, wie es ihn unter OS X gibt. Er hat keine Titelleiste und wird zusammen mit dem Elternfenster bewegt.
Ich glaube sogar (weiß es aber nicht mit Sicherheit, da ich keinen Mac besitze), dass dies auch funktioniert, wenn der Dialog modal ist - in diesem Falle sind nur die Steuerelemente des Parents blockiert, das Fenster lässt sich aber immer noch klicken.

Bei Windows ist das sehr störend: wenn man einen modalen Dialog hat, und die Anwendung nur mal kurz zur Seite schieben will, muss man den Dialog erst abbrechen, das Fenster bewegen und anschließend die Dialog wieder anzeigen. Bei modeless Dialogen muss man beim Verschieben des Elternfensters (z. B. auf einen zweiten Monitor) alle Kind-Fenster einzeln nachziehen.

Die Idee war nun, beim Bewegen des Hauptfenster die modeless Kinder automatisch mitzubewegen. Wenn dies nicht gewünscht ist, dann kann der Nutzer einfach Strg gedrückt halten.
Wenn der Nutzer ein modales Kind verschiebt und dabei Strg gedrückt hält (hier also negative Logik), dann wird auch das Elternfenster mit bewegt.

Dies kann durchaus (je nach Anwendung) sehr nutzerfreudlich sein.
Mal sehen, ob ich das mit dem JNA hinbekomme... Könnte ich mich bei Bedarf nochmal melden?

 

[jf]

Die gute Nachricht:
ich habe das mit JNA hinbekommen! Fetzt! :toll:

Die schlechte Nachricht:
in meiner Demo funktioniert es ja sehr gut - aber sobald ich den Code der Listener-Prozedur einbaue, schmiert mir meine Anwendung weg ;(
Java(TM) Platform SE binary funktioniert nicht mehr

Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: javaw.exe
Anwendungsversion: 6.0.230.5
Anwendungszeitstempel: 4cddca06
Fehlermodulname: java.dll
Fehlermodulversion: 6.0.230.5
Fehlermodulzeitstempel: 4cddfd83
Ausnahmecode: c0000005
Ausnahmeoffset: 00004e2f
Betriebsystemversion: 6.1.7601.2.1.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: 1ec0
Zusatzinformation 2: 1ec0fd70d07d060e5bfcf53c69ad1739
Zusatzinformation 3: 2c48
Zusatzinformation 4: 2c48940de5e7d1cb2e131ad6a0ca2feb

Lesen Sie unsere Datenschutzbestimmungen online:
Windows 7-Datenschutzbestimmungen - Microsoft Windows

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
C:\Windows\system32\de-DE\erofflps.txt

Kann mir da jemand weiterhelfen? ???:L


[EDIT]
Jetzt läuft es!!! :applaus:
Scheinbar musste ich erst noch eine alte Instanz meiner Anwendung beenden, bevor die neue Version funktioniert.
[/EDIT]