SWT Operation auf GUI-Komponente kommt mal wieder nicht an...

[hdi]

Hey,
ich müh mich ja grad gezwungermaßen (Plugin für Eclipse) mit SWT ab.
Jetzt tut der EDT schon wieder nicht was ich will:

    @Override
    public void handleEvent(Event e) {
	log.showButton(false);
	doImport();
	log.showButton(true);
    }

diese showButton Methode delegiert einfach an die setVisible() eines Buttons.
Anfangs ist der Button nicht sichtbar, und nachdem doImport() abgearbeitet wurde (läuft nicht in einem neuen Thread) wird der Button angezeigt. Also so wie man es erwartet.

ABER: Wenn er erstmal sichtbar ist und dieses Event wird wieder ausgelöst, verschwindet er nicht bis doImport() fertig ist. So als würde die erste Zeile in der handleEvent() nicht drin stehen.

Ich befürchte ja ihr kommt schon wieder mit asynch/syncExec usw, was bisher bei mir IMMER zu ner Exception geführt hat aber wer weiss

Ich versteh das Konzept von SWT da eh noch gar nicht. zB in der doImport() werden diverse setText()-Aufrufe auf ein Label gemacht, und die Änderung sieht man auch on-the-fly, d.h. diese Events kann er nicht hinter die handleEvent-Methode schieben - die werden sofort ausgeführt! Aber wieso geht dann das hier nicht...

Danke für eure Hilfe!

 

[Wildcard]

Das hat nichts mit SWT im speziellen zu tun, du verstehst im allgemeinen nicht wie grafische Oberflächen funktionieren
Du darfst long Running Operations niemals im UI Thread ausführen. Es muss also ein neuer Thread her für deinen Import.
Dieser Thread darf niemals die Oberfläche (direkt, oder indirekt) verändern, sonst fliegt eine InvalidThreadAccess Exception. Wenn du in dem Thread die Oberfläche verändern willst, dann musst du diesen Aufruf vom UI Thread ausführen lassen, dazu dann Display#(a)syncExec.

 

[hdi]

Wildcard ich versteh das durchaus, und mit Swing hab ich da auch keine Probleme. Mir ist auch klar dass dieser Code in Swing so nicht funktionieren würde, aber:

zB in der doImport() werden diverse setText()-Aufrufe auf ein Label gemacht, und die Änderung sieht man auch on-the-fly, d.h. diese Events kann er nicht hinter die handleEvent-Methode schieben - die werden sofort ausgeführt!

Hier wird also innerhalb einer long running operation etwas in der GUI verändert und das funktioniert halt auch - geht wohl in SWT also und da frage ich mich wieso dann nicht genauso das Ändern der Sichtbarkeit geht.

...Problem ist dass dieses asynch/syncExec oder die Job-Klasse bei mir bisher nicht funktioniert haben, das klingt schon alles sinnig für mich aber ich bekomme immer diese Exception dass ein falscher Thread drauf zugreift :bahnhof: Das Konzept ist mir ja klar in Swing funzt das bei mir auch gut aber in SWT geht da nix.

 

[Wildcard]

Wildcard ich versteh das durchaus, und mit Swing hab ich da auch keine Probleme.

Falsch, in Swing merkst du nur nicht das du ein Problem hast (bis dein Problem beim Kunden aufschlägt).
Das Threading Modell von SWT und Swing ist identisch, nur das SWT früh fehlschlägt (wie es sein sollte) und Swing in Threading Issues rennt, was wesentlich schlimmer ist.

...Problem ist dass dieses asynch/syncExec oder die Job-Klasse bei mir bisher nicht funktioniert haben, das klingt schon alles sinnig für mich aber ich bekomme immer diese Exception dass ein falscher Thread drauf zugreift

Weil nur der UI Thread die Oberfläche ändern darf (wie in Swing) und das versucht dir die Exception zu sagen. Zeig den Code der die Exception wirft, dann kann ich dir auch helfen.

:bahnhof: Das Konzept ist mir ja klar in Swing funzt das bei mir auch gut aber in SWT geht da nix.

Siehe oben, das ist falsch. Swing hat identische Restriktionen nur werden sie nicht forciert. Sei froh das dir SWT diesen Fehler wirft, sonst wüsstest du nämlich gar nicht das du etwas falsch machst.

 

[hdi]

Falsch

Neeeeee!! *whine* Ich verstehe es echt bitte glaub mir

// method entered by EDT i.e. listener
button.setText("Processing...");
new Thread(){
     public void run(){
           calculateSomething();
           EventQueue.invokeLater(new Runnable(){
                  public void run(){
                       button.setText("DONE!");
                  }
            }
     }
}.start();

So macht man das doch in Swing, oder etwa nicht? Und hier wird kein Fehler auftreten nicht weil Swing da nicht sofort reagiert, sondern weil es keinen gibt.

Das ist mir sonnenklar! Leider funzt das hier bei mir mit SWT irgendwie nicht so recht, aber ich versuch jetzt noch rum. Das ist allein schon scheisse zu testen weils n Plugin ist und ich ständig ne neue Eclipse App starten muss, im Debug-Modus geht's auch net weil da werden mir keine konkreten Fehler angezeigt usw. Display.getCurrent()/Default liefert grad immer null , nervt alles etwas grad.. :bae:

Ich versuch's jetzt nochmal Zeile für Zeile das muss ja gehen echt -.-

 

[Wildcard]

Neeeeee!! *whine* Ich verstehe es echt bitte glaub mir

Das System ist 1:1 identisch...

// method entered by EDT i.e. listener
button.setText("Processing...");
new Thread(){
     public void run(){
           calculateSomething();
           EventQueue.invokeLater(new Runnable(){
                  public void run(){
                       button.setText("DONE!");
                  }
            }
     }
}.start();

So macht man das doch in Swing, oder etwa nicht? Und hier wird kein Fehler auftreten nicht weil Swing da nicht sofort reagiert, sondern weil es keinen gibt.

In deinem Fall ändert doImport aber die UI und das ist auch in Swing verboten.

Das ist mir sonnenklar! Leider funzt das hier bei mir mit SWT irgendwie nicht so recht, aber ich versuch jetzt noch rum. Das ist allein schon scheisse zu testen weils n Plugin ist und ich ständig ne neue Eclipse App starten muss, im Debug-Modus geht's auch net weil da werden mir keine konkreten Fehler angezeigt usw. Display.getCurrent()/Default liefert grad immer null , nervt alles etwas grad.. :bae:

Der Debug Mode funktioniert auch bestens bei Eclipse Plugins...
Display.getCurrent liefert in einem non-UI Thread grundsätzlich null und das steht auch so in der API-Doc.
Display.getDefault liefert mit an Sicherheit grenzender Wahrscheinlichkeit allerdings nicht null
Besser wäre allerdings wenn dein Thread direkt das richtige Display von aussen mitbekommt.

 

[hdi]

In deinem Fall ändert doImport aber die UI und das ist auch in Swing verboten.

Jo ich weiss das war ja nur ein Bsp grad. Hab ich eben alles schon mal gemacht gehabt - siehe anderer Thread hier irgendwo in diesem Unterforum aber es hat immer geknallt.

Display.getDefault liefert mit an Sicherheit grenzender Wahrscheinlichkeit allerdings nicht null

Dann war das wohl noch nicht refreshed & ich hätte neu starten müssen kann sogar sein. (Eig. war ich aber im Debug-Modus)

Besser wäre allerdings wenn dein Thread direkt das richtige Display von aussen mitbekommt.

Jo hab ich jetzt so gemacht - passt

...Naja also wenn's ich jetzt ja doch richtig verstanden hab muss es sich ja um nen Flüchtichkeitsfehler handeln dass ich noch immer ne Exception krieg, ich wär mir nicht bewusst SWT-alpha-0.0.0.01 heruntergeladen zu haben xD

Ich meld mich wenn ich noch immer nicht weiterkomm. Ansonsten nochmal danke zur Klärung ich dachte mir ja eig schon dass es so wie in Swing funktioniert aber war mir dann nicht mehr sicher als ich immer nur Fehler gekriegt hab.

 

[Wildcard]

Du bekommst also weiterhin eine InvalidThreadAccess Exception? Du solltest recht leicht am Stacktrace ablesen können wo du vergessen hast Display#asyncExec aufzurufen. Falls nicht, poste mal Stacktrace + passender Code dann sollten wir das Problem fix beheben können...
Übrigens: für Background Jobs würde ich dir die Eclipse Jobs API empfehlen. Kinderleicht zu bedienen und nimmt dir viele Sorgen ab...

 

[hdi]

Puh... FINALLY!
Jetzt geht alles - immer wieder komisch wie man denkt man hat eine Sache so schon mal 1:1 probiert und es ging nicht - und "plötzlich" geht's

Ein Jammer nur dass meine doImport() Methode jetzt aussieht wie ein Haufen Sch***
Ist ein Problem wenn die Logik darin stark von Werten aus GUI-Komponenten abhängt, da man ständig Runnables machen muss für den synchExec()-call, dann kann man natürlich nur auf finals zugreifen und oft geht nicht mal das weil die Klassen anonym sind.

Jetzt musste ich mir ein paar Instanzvariablen anlegen damit ich überhaupt Zugriff auf manche Dinge hab...

Naja whatever wenigstens geht es jetzt. Danke für deine Geduld :toll:

PS: Der nächste Thread kommt sehr bald denn ich steh jetzt grad schon vor dem nächsten Problem Aber ich müh mich jetzt noch n bisschen selber damit ab bevor ich dich weiter belaste

edit: Diese Job Klasse schau ich mir jetzt auch nochmal an thx. Vllt krieg ich den Code damit etwas aufgeräumt.

 

[Wildcard]

Du könntest zB von IProgressMonitor ableiten und eigene Methoden anbieten um die GUI asynchron aus dem Job heraus zu aktualisieren. Deinen eigenen ProgessMonitor wrapst du dann um den den der Job übergeben bekommt damit du auch weiterhin Progress reporten kannst.