Der EventQueue javadoc gibt an, dass in Reihenfolge eingereihte Ereignisse sequenziell und in der Reihenfolge ausgelöst werden müssen.
Stimmt es, dass Runnable s, die mit EventQueue.invokeLater in eine Warteschlange eingereiht wurden, garantiert vor den nachfolgenden Benutzerereignissen (z. B. MouseEvent ) verteilt werden? Mit anderen Worten, ein Event-Handler kann vor dem eingereihten Runnable ausgeführt werden, wenn das Benutzerereignis nach EventQueue.invokeLater aufgetreten ist.
Danke!
Wahrscheinlich ist es am besten zu erklären, was Sie zu tun versuchen. Im Allgemeinen ist das Ereignisversandsystem so konzipiert, dass Sie sich nicht über seine Interna im Klaren sein sollten. Wenn Sie einen Ereignishandler schreiben, der die Benutzeroberfläche direkt aktualisiert, kann es sinnvoll sein, kein Runnable zu verwenden und Ihre Aktualisierungen inline auszuführen. Wenn Ihr Ereignishandler einige Berechnungen oder eine Verarbeitung durchführt, die einen unbestimmten Zeitraum in Anspruch nimmt, möchten Sie jedoch einen Thread verwenden, der schließlich das UI-Update mit einem Runnable mit dem Swing.invokeLater-Aufruf durchführt. Wenn Sie die Abfolge der Ereignisse wissen müssen, während sie gesendet werden, bedeutet das, dass Sie versuchen, Annahmen in Ihrer Logik zu erstellen, die wahrscheinlich woanders hingehören.
Betrachten Sie zum Beispiel einen Mausklick-Ereignishandler, der eine starke Verarbeitung (Netzwerkdownloads oder DBMS-Abfragen) in einem Thread ausführt und später eine Textbezeichnung in der Benutzeroberfläche aktualisiert. Sie möchten wahrscheinlich sicherstellen, dass die Verarbeitung und die UI-Aktualisierung durchgeführt werden, bevor der Benutzer auf eine andere Stelle auf der Benutzeroberfläche klickt, um Mehrdeutigkeiten zu vermeiden, bei denen Klicks verarbeitet werden. In einem solchen Fall würden Sie wahrscheinlich die Benutzeroberfläche oder bestimmte anklickbare Teile der Benutzeroberfläche sofort im ersten Mausklick-Ereignis deaktivieren, sodass die Benutzeroberfläche reaktionsfähig bleibt, aber Ihren onMouse-Handler vor erneuter Eingabe schützt, bis das ursprüngliche Klickereignis vollständig verarbeitet wurde. (Verzeih den folgenden Ausschnitt, wie es Jahre her ist, seit ich Swing gemacht habe, es ist mehr wie Pseudo-Code.)
%Vor%Die Idee hier ist, dass Sie Ihre Logik so schreiben, dass sie nicht von der zufälligen Reihenfolge der Ereignisse abhängt, sondern anerkennt, dass die Verarbeitung wahrscheinlich länger dauert als das nächste ankommende Mausereignis und Vorkehrungen für ein solches Timing trifft . Eine subtile Verbesserung wäre, auch einen Fortschrittsindikator oder Fortschrittszähler zu zeichnen, um anzuzeigen, dass mit dem Benutzer gearbeitet wird.
Die API-Dokumentation gibt an, dass Ereignisse
sindIn der Reihenfolge, in der sie in die Warteschlange eingereiht werden.
Aber wenn Sie den Quellcode überprüfen, werden Sie sehen, dass das nicht immer der Fall ist, obwohl es für die meisten Zwecke weitgehend korrekt ist.
Tags und Links java swing awt event-dispatch-thread