miffi
Erfahrenes Mitglied
Howdie.
Das Problem scheint gelöst zu sein, aber ich will noch meinen Senf dazu abgeben
Hab mich auch schon öfter mit der guten JProgressBar und anderen Swing-Komponenten rumschlagen dürfen...
Bei mir hat sich das Problem aufgrund von Performance-Fragen automatisch erübrigt. Da ich fast ausschließlich hardware-nah programmiere (JNI/JNA), ist einer der größten Knackpunkte die Performance. Wenn z.B. eine Firmware auf eine Hardware gespielt werden soll, soll die Übertragung nicht (bzw. so wenig wie möglich) durch den AWTEventThread ausgebremst werden. Im Prinzip mache ich genau wie Nadriel ein eigenes Runnable, das im Konstruktor die entsprechenden Objekte entgegennimmt. Dieses Runnable hat eine Queue (z.B. eine java.util.LinkedList), in die von außen States gelegt werden können.
In der run()-Methode läuft eine Schleife, welche die States aus der Queue pollt. Ist ein State vorhanden, wird das ProgressBar damit aktualisiert. Das bringt zwar keine 100% synchrone Darstellung zum eigentlichen Arbeits-Status, aber es reicht aus, um den Benutzer mit Informationen zu versorgen. Die Setter-Methode für States kann sofort zurückkehren, da sie nur ein oder mehrere Objekte in die Queue packen muss, ohne das GUI aktualisieren zu müssen.
Seit ich dieses Queue-Verfahren verwende habe ich kein Problem mehr mit Komponenten wie ProgressBars. Aber das fällt natürlich flach, falls eine absolut synchrone Darstellung eines Arbeitsprozesses stattfinden soll.
Gruß
miffi
Das Problem scheint gelöst zu sein, aber ich will noch meinen Senf dazu abgeben
Hab mich auch schon öfter mit der guten JProgressBar und anderen Swing-Komponenten rumschlagen dürfen...
Bei mir hat sich das Problem aufgrund von Performance-Fragen automatisch erübrigt. Da ich fast ausschließlich hardware-nah programmiere (JNI/JNA), ist einer der größten Knackpunkte die Performance. Wenn z.B. eine Firmware auf eine Hardware gespielt werden soll, soll die Übertragung nicht (bzw. so wenig wie möglich) durch den AWTEventThread ausgebremst werden. Im Prinzip mache ich genau wie Nadriel ein eigenes Runnable, das im Konstruktor die entsprechenden Objekte entgegennimmt. Dieses Runnable hat eine Queue (z.B. eine java.util.LinkedList), in die von außen States gelegt werden können.
In der run()-Methode läuft eine Schleife, welche die States aus der Queue pollt. Ist ein State vorhanden, wird das ProgressBar damit aktualisiert. Das bringt zwar keine 100% synchrone Darstellung zum eigentlichen Arbeits-Status, aber es reicht aus, um den Benutzer mit Informationen zu versorgen. Die Setter-Methode für States kann sofort zurückkehren, da sie nur ein oder mehrere Objekte in die Queue packen muss, ohne das GUI aktualisieren zu müssen.
Seit ich dieses Queue-Verfahren verwende habe ich kein Problem mehr mit Komponenten wie ProgressBars. Aber das fällt natürlich flach, falls eine absolut synchrone Darstellung eines Arbeitsprozesses stattfinden soll.
Gruß
miffi
