Swing Anzeige des Warten-Cursors

[kodela]

Hallo,

ich habe ein Problem mit dem Warten-Cursor, genauer gesagt, mit der Umschaltung vom Normal-Cursor auf den Warten-Cursor, die über den Aufruf

strApp.setCursor(Cursor.getPredefinedCursor(Cursor.WAIT_CURSOR));

realisiert wird und immer funktioniert, wenn sich der Normal-Cursor zum Zeitpunkt der Umschaltung im Bereich des Hauptfensters befindet. Es kann allerdings passieren, dass dies bei bestimmten Aktionen, zum Beispiel wenn über Strg+V etwas eingefügt und etwas zeitaufwendig geprüft werden soll, der Normal-Cursor sich außerhalb des Anwendungsfensters befand. In solchen Fällen wird der Warten-Cursor nicht angezeigt, auch wenn der Mauszeiger während der Wartezeit in das Fenster gezogen wird.
Wie kann man dieses Verhalten ändern, dass der Warten-Cursor (während einer Wartezeit) immer angezeigt wird, wenn sich der Mauszeiger im Anwendungsfenster befindet. Mit dem zusätzlichen vorangestellten Aufruf von

strApp.setAutoRequestFocus(true);

erreiche ich dies nicht.

Vorweg schon einmal danke für jeden Tipp.

 

[mrbela]

Hi kodela,

in welcher GUI Umgebung befindest Du Dich denn? Swing, JavaFX, SWT?

Auch wäre es sinnvoll zu wissen, von welchem Typ 'strApp' (ganzer Pfad) und auch Cursor.

Danke schonmal für die Auskunft.

 

[LimDul]

Wahrscheinlichste Ursache: Die langlaufende Bearbeitung ist nicht in einen eigenen Thread ausgelagert. Dadurch wird die gesamte Gui blockiert.

Lösung: Die langlaufende Bearbeitung in einen eigenen Thread auslagern und entsprechend synchronsieren.

 

[kodela]

Hallo mrbela,

ja, zumindest auf einen Teil Deiner Fragen wollte ich in meinem Beitrag eingehen, aber dann habe ich es doch vergessen.
Die Hauptklasse der Anwendung ist 'StradokuApp' vom Typ JFrame, also eine Swing Umgebung. 'strApp' ist eine Referenz auf die Klasse 'StradokuApp'. Mittlerweile habe ich allerdings das Handling für den Wait-Cursor etwas geandert und dafür in 'StradokuApp' die Methode 'setWaitCursor()' eingeführt, die sieht so aus.

    public void setWaitCursor(boolean set) {
        if (set) {
            setCursor(Cursor.getPredefinedCursor(Cursor.WAIT_CURSOR));
        } else {
            setCursor(Cursor.getPredefinedCursor(Cursor.DEFAULT_CURSOR));
        }       
    }

An meinem Problem hat sich damit allerdings nichts geändert.

Die GUI selbst wurde mit dem GUI-Builder von NetBeans 8.2 erstellt. Der Cursor ist als 'awt.Cursor(java.awt.Cursor.DEFAULT_CURSOR)' definiert. Entwicklungsumgebung ist Windows 10.

Sollte ich nicht alles so beantwortet haben, wie Du es erwartest, dann liefere ich gerne nach.

Gruß, kodela

 

[mrbela]

Danke für die Infos.
Das Problem wird das sein, das LimDul schon vermutete:

Man sollte immer aufwändige, länderlaufende Operationen in einen eigenen Thread auslagern. Aus diesem "Arbeiter-Thread" heraus könntest Du, da Du in Swing bist, mit SwingUtilities.invokeLater dann den Cursor auf wartend (und am Ende der Abarbeitung wieder auf normal) setzen. Schau mal hier, da findest Du ein kleines Beispiel dazu.

Kennst Du Dich mit Threads aus, bzw. weißt Du was das ist?

 

[kodela]

Danke für die Antworten!

Ja, ich weiß was Threads sind und es laufen mehrere davon in meiner Anwendung, zum Beispiel für die laufende Zeitanzeige, für die Generierung oder den Ausdruck von Stradokus (Str8ts) und für den Import einer Stradoku-Liste. Damit habe ich keine Probleme.

In der aktuellen Situation, Stradokus sollen auf Eindeutigkeit geprüft werden, gibt es allerdings solche. Diese Eindeutigkeitsprüfung lief bei mir bereits unter einem eigenen Thread und das funktionierte auch - bis auf eine Ausnahme. Um die zu beschreiben, muss ich etwas ausholen:

Der Anwender soll selbst Stradokus "basteln' können (wer nicht weiß, was das sind, es sind Str8ts, die wiederum sind den Sudokus ähnlich, haben aber auch schwarze Zellen). Dafür werden in das Raster erst schwarze Zellen und mindestens ein Vorgabewert eingetragen. Das Programm versucht diese Eingabe zu lösen. In seltenen Fällen muss dafür der Vorgabewert geändert werden. Die gefundene Lösung ist bei nur einem Vorgabewert natürlich nicht eindeutig, was aber für das weitere Vorgehen keine Rolle spielt.

Im nächsten Schritt kann der Anwender nun die vom Programm gefundene Lösung bearbeiten, das bedeutet, dass er Vorgabewerte entfernen oder in den schwarzen Zellen Sperrwerte setzen kann. Nach jeder solchen Aktion (es können auch mehrere in Folge sein) kann das Stradoku geprüft werden. Eine solche Prüfung bezieht sich auf die Lösbarkeit, den Schwierigkeitsgrad und die Eindeutigkeit. Ein Stradoku ist nur dann eindeutig, wenn es genau eine Lösung gibt. Kann das Stradoku mit einem Level von 1 - 4 gelöst werden, dann ist es auch eindeutig. Kann es gelöst werden, aber nicht mit einem der Level 1 - 4, dann ist es nur gültig und hat den Level 5, wenn es eindeutig lösbar ist. Dieses Prozedere wird so lange fortgesetzt, bis man ein Stradoku mit dem gewünschten Level hat.

Um die Eindeutigkeit festzustellen, muss für jede freie Zelle geprüft werden, ob das Stradoku durch Einsetzen aller Ziffern, die nicht Lösungswert sind, gelöst werden kann. Nur wenn dies für keine einzige der freien Zellen möglich ist, ist das Stradoku gültig und hat den Level 5.

Diese Eindeutigkeitsprüfung arbeitet in einem eigenen Thread grundsätzlich einwandfrei. Es gibt nur eine einzige Ausnahme. Wenn bei dieser Eindeutigkeitsprüfung genau der erste Lösungsversuch ergibt, dass das Stradoku nicht gelöst werden kann, was sehr selten vorkommt, stürzt die Anwendung ab. Java selbst arbeitet nicht mehr und muss über den Taskmanager beendet werden.

Läuft die Eindeutigkeitsprüfung nicht über einen eigenen Thread (jedoch mit dem selben Code), dann tritt dieses Problem nicht auf. Ich habe Tage damit verbracht, die Ursache für dieses eigenartige Verhalten zu ergründen - es ist mir nicht gelungen. Allein wegen dieses Problems habe ich einen Warte-Dialog mit Fortschrittsanzeige über Bord geworfen und habe mich mit einem Hinweis in der Statuszeile sowie dem Warte-Cursor begnügt.

So viel zum Verständnis dafür, dass ich für die Eindeutigkeitsprüfung auf einen eigenen Thread verzichten muss.

Gruß, kodela

 

[mrbela]

Prinzipiell, das sagt mir mein Bauch, solltest Du auf nichts verzichten (bspw. "Eindeutigkeitsprüfung auf einen eigenen Thread"), weil es irgendwie nicht funktioniert.
Du schreibst, dass Java abstürzt. Crash es richtig (dann könnte man über eine Fehlermeldung an der richtigen Stelle (Stichwort Logging) den Grund herausfinden) oder "friert" die Anwendung ein. Sollte letzteres der Fall sein, dann spricht das spontan gesagt für einen Deadlock. Den Grund hierfür zu finden (generell für Deadlocks) gehört aber zu einer der schwierigsten Aufgaben in der Programmierung (Stichwort "Race condition").

Zurück zu Deiner Anwendung: Auch wenn es Dir wenig hilft -sorry-, aber die aufwändige Eindeutigkeitsprüfung würde ich wieder auslagern. Dann wirst Du auch das Problem mit dem Cursor nicht mehr haben.. Dafür dann das andere, ich weiß. Aber das ist ein Fehler, der dann zu beheben ist.

Wenn Du magst kannst Du ja auch mal den Code teilen.. Aber ob ich/wir auf die Schnelle da einen Fehler (Deadlock, oder evtl. was ganz anderes) finden, kann ich Dir natürlich nicht versprechen.

 

[kodela]

Hallo mrbela,

danke für die Antwort und Dein Angebot. Ich stelle eben das Projekt mit der Version, in der die Eindeutigkeitsprüfung in einem eigenen Thread erfolgte, zusammen. Bin damit noch nicht fertig und muss jetzt meine Arbeit damit einstellen. Morgen melde ich mich dann wieder.

Gruß, kodela

 

[kodela]

Prinzipiell, das sagt mir mein Bauch, solltest Du auf nichts verzichten (bspw. "Eindeutigkeitsprüfung auf einen eigenen Thread"), weil es irgendwie nicht funktioniert.

Danke, ich habe es mir zu Herzen genommen - und, ich brauche für die Eindeutigkeitsprüfung auf einen eigenen Thread nicht zu verzichten.

Gruß, kodela