# Verzögerung à la Tooltip bei mouseEntered



## Wolfgang Lenhard (13. Mrz 2009)

Hi,
ich stehe gerade auf dem Schlauch: Ich möchte für die Buttons einer Anwendung nicht nur Tooltips anzeigen, sondern nachdem die Maus eine gewisse Zeit über dem Button geruht hat, soll schließlich auch eine Audioerklärung starten. Ich habe allerdings keine vernünftige Idee, wie die Verzögerung am Besten zu realisieren ist. Das Audio soll nicht einfach nur verzögert wiedergegeben werden, da sich für die Wiedergabe der Zeiger noch über dem Button befinden soll. Wie prüft man denn am schlausten bei einem MouseEvent, ob sich die Maus nach einer gewissen Latenzzeit noch über dem Button befindet? Wie macht das ein Tooltip?

Viele Grüße und vielen Dank,
  Wolfgang

P.S.: Sollte man das über mouseEvent.getComponent() abfangen und prüfen, ob sich x- und y-koordinate des Mauszeigers noch über der Komponente befinden, oder geht es auch einfacher?


----------



## Verjigorm (13. Mrz 2009)

Maus drüber -> flag setzen
Maus weg -> flag zurücksetzen

Wenn Maus drüber -> Starte Thread, warte x ms, schaue ob flag immer noch gesetzt
Ja -> Spiele Audio
Nein -> Ende


----------



## Wolfgang Lenhard (13. Mrz 2009)

Ah, ok! Vielleicht ist das wirklich ein praktikabler Ansatz. Ich denke, ich mache ein Singelton, damit der Code-Wildwuchs nicht zu sehr zunimmt. Danke!


----------



## Ebenius (17. Mrz 2009)

Nur als Ergänzung: An der Stelle bietet sich eigentlich der javax.swing.Timer anstatt eines Threads an.

Ebenius


----------



## Verjigorm (17. Mrz 2009)

Gibt es irgendwo ne Übersucht Thread vs Timer?
Grad bissl gegoogelt aber nix berauschendes gefunden.
Ich kann mir nie merken, wann und wieso man einen Timer benutzen soltle


----------



## Ebenius (17. Mrz 2009)

Swing Timer (javax.swing.Timer) benutzt man, wenn billige GUI-Änderungen verzögert oder wiederholt GUI-Inhalte ausführen möchte. Der Action Listener wird vom EDT aufgerufen. Klassischer Anwendungsfall wäre: [HIGHLIGHT=Java]final String[] waitTexts = { "Hold on .", "Hold on ..", "Hold on ..." };
final JLabel waitLabel = new JLabel(waitTexts[0]);
new javax.swing.Timer(500, new ActionListener() {

  int textIndex = 0;

  @Override
  public void actionPerformed(ActionEvent e) {
    waitLabel.setText(waitTexts[++textIndex % waitTexts.length]);
  }
}).start();[/HIGHLIGHT]
Ebenius


----------



## Verjigorm (17. Mrz 2009)

Also ich spare mir quasi das invokeLater, welches ich in einem Thread benutzen würde um GUI-Elemente aus dem Thread raus zu verändern?


----------



## Ebenius (17. Mrz 2009)

Verjigorm hat gesagt.:


> Also ich spare mir quasi das invokeLater, welches ich in einem Thread benutzen würde um GUI-Elemente aus dem Thread raus zu verändern?


... und Du sparst Dir einen extra Thread, was ganz sicher nicht zu verachten ist.

Ebenius


----------



## Verjigorm (17. Mrz 2009)

Hm ich bin davon ausgegangen, dass Timer intern auch einen Thread benutzt


----------



## Illuvatar (17. Mrz 2009)

Wolfgang Lenhard hat gesagt.:


> Ah, ok! Vielleicht ist das wirklich ein praktikabler Ansatz. Ich denke, ich mache ein Singelton, damit der Code-Wildwuchs nicht zu sehr zunimmt. Danke!



Ähm... das ist selten zu empfehlen. Siehe zum Beispiel hier:
http://www.java-forum.org/java-basics-anfaenger-themen/80294-singleton-diesem-fall-sinnvoll.html


----------



## Ebenius (17. Mrz 2009)

Verjigorm hat gesagt.:


> Hm ich bin davon ausgegangen, dass Timer intern auch einen Thread benutzt


Genau einen. Den EDT. 

Ebenius


----------



## Gast2 (17. Mrz 2009)

Soviel ich weiß ist der ToolTipManager auch ein Singleton...


----------



## tfa (17. Mrz 2009)

Ebenius hat gesagt.:


> Genau einen. Den EDT.


Und den, der in javax.swing.TimeQueue gestartet wird. Wie soll das auch nur mit einem funktionieren?


----------



## Ebenius (17. Mrz 2009)

tfa hat gesagt.:


> Und den, der in javax.swing.TimeQueue gestartet wird. Wie soll das auch nur mit einem funktionieren?


Hab mich blöd ausgedrückt. Es wird halt für alle Swing Timers nur eine einzige Instanz der TimerQueue verwendet.

Ebenius


----------



## Wolfgang Lenhard (17. Mrz 2009)

Vielen Dank für den Hinweis auf die Timer-Klasse, die wirklich einen Blick wert ist.

Zur Singleton-Problematik: Ich sehe hier ehrlich gesagt keine Alternative. Ansonsten könnte es sein, dass mehrere Erklärungen gleichzeitig abgespielt werden. In einer Singleton-Klasse lässt sich das prima handhaben: Entweder wird ein laufender Sound abgebrochen, wenn ein neuer gestartet werden soll, oder es wird kein neuer gestartet, falls gerade noch einer läuft. Ist ja im Grunde das gleiche wie bei den Tooltips: Da ist stets nur einer sichtbar.
Design-Fragen sind in diesem Fall für mich offen gesagt eher nebensächlich, da der Anwender nicht die Schönheit des Codes sondern die Handhabbarkeit des Programms bewertet.


----------



## Wildcard (17. Mrz 2009)

Geht es hier um Accessibility? Wenn ja, warum verwendest du nicht die built-in Accessibiltiy?


----------



## Wolfgang Lenhard (17. Mrz 2009)

Was meinst Du genau?


----------



## Wildcard (17. Mrz 2009)

Na für mich hört sich das nach Support für Menschen mit zB Sehbehinderung an und da würde ich nicht das Rad neu erfinden.


----------



## Wolfgang Lenhard (18. Mrz 2009)

Ach so. Ja, das wäre ein gutes Beispiel. Im konkretenb Fall geht es um Software für Kinder in der Schuleingangsphase und für leistungsschwache Kinder in der Grundschule, die noch nicht unbedingt lesen können. Es ist ein Programm zur Therapie von Dyskalkulie.


----------



## Wildcard (18. Mrz 2009)

Nun, ich weiß nicht ob da ganz spezielle Anforderungen gegeben sind, aber durch Java Accessibility besteht eben schon die Integration an den Accessibility Layer des Betriebssystems (Screenreader und der Gleichen).


----------

