Foxtrot doch nicht so super.

[thE_29]

Da hier: http://www.java-forum.org/de/viewtopic.php?t=27136&start=90

und speziell da: http://www.javalobby.org/eps/galbraith-swing-2/ diese Foxtrot API angesprochen wird, dachte ich mir, ich verbaue das Teil mal...


Tjo, gesagt getan! Ich habe mir mal einen eigenen Listener (in einem Projekt) gebastelt, denn wenn ich den über eine JComponent lege immer auf Maus und KeyEvents reagiert.

Dort drinnen gibt es eine Methode "invoke" welche den aufgerufen wird, wenn eben einer diese 2 Events auftritt! Um das einfriereren der GUI zu verhinderen dachte ich mir ich baue das gleich bevor ich die invoke Methode aufrufe ein (also foxtrot).

Das sieht ungefähr so aus:

        if(pressed)
        {
          pressed = false;
          if(adapter != null)
          {
            foxtrot.Worker.post(new foxtrot.Job(){
              public Object run()
              {
                component.setEnabled(false); //wenn er nicht enabled wäre, könnte man nicht klicken
                adapter.invoke(e);
                component.setEnabled(true);
                return null;
              }
            });
          }
        }

Ich wollte halt, das der Button oder was auch immer disabled wird, die eigentliche Methode (via invoke) ausgeführt (also auf was man im Listener reagiert) und dann die Komponente wieder enablen!

So, das ganze klappt wenn ich vom ersten JFrame ausgehe (der nicht via dem Listener aufgerufen wird).

Klicke ich dann von dem JDialog 1 mit Foxtrot und dem Listener auf nen 2ten JDialog mit Foxtrot und dem Listener so reagiert der Button nicht mehr! Bzw Foxtrot geht nicht mehr, also wenn ich mit debuge geht der irgendwie nicht mehr in diesen Job rein..

public class Testor extends JFrame
{
private static class FDialog extends JDialog
  {
    private static int dlgCounter = 1;
    public FDialog(int dlgCount, JFrame owner)
    {
      super(owner, "Dialog " + dlgCount + "  Insgesamt: " + dlgCounter, true);
      init(dlgCount);
    }
    
    public FDialog(int dlgCount, JDialog owner)
    {
      super(owner, "Dialog " + dlgCount + "  Insgesamt: " + dlgCounter, true);
      init(dlgCount);
    }
    
    private void init(final int dlgCount)
    {
      final JButton testButton = new JButton("Hit me " + dlgCount);
      testButton.addMouseListener(new MouseAdapter() {
        public void mousePressed(MouseEvent e)
        {
          foxtrot.Worker.post(new foxtrot.Job(){
            public Object run()
            {
              testButton.setEnabled(false);
              FDialog dlg = new FDialog(dlgCount + 1, FDialog.this);
              dlg.setVisible(true);
              testButton.setEnabled(true);
              return null;
            }
          });
        }
      });
      dlgCounter++;
      this.getContentPane().add(testButton);
      this.setSize(200 + (dlgCount * 10),200 + (dlgCount * 10));
      this.setLocationRelativeTo(getParent());
    }
  }

  public Testor() throws Exception
  {
    super();
    final JButton testButton = new JButton("Hit me");
    testButton.addMouseListener(new MouseAdapter() {
      public void mousePressed(MouseEvent e)
      {
        foxtrot.Worker.post(new foxtrot.Job(){
          public Object run()
          {
            testButton.setEnabled(false);
            FDialog dlg = new FDialog(1, Testor.this);
            dlg.setVisible(true);
            testButton.setEnabled(true);
            return null;
          }
        });
      }
    });
    this.getContentPane().add(testButton);
    this.setSize(300,300);
    this.setLocationRelativeTo(getParent());
    this.setVisible(true);

  public static void main( String[] args ) throws Exception
  {
     new Testor();
   }
}

Hier ein KSKB!

Bin gerade beim Erstellen des KSKB draufgekommen, das es anscheinend mit dem JDialog und setModal zum tun hat! Wenn die JDialogs nicht modal sind, klappt es einwandfrei.. Nur brauche ich modale Dialoge..

Hier noch wie das Problem aussieht: Klickt man beim JFrame auf den Button so öffnet sich der FDialog! Klickt man hier auf den Button drauf, passiert nix.. (man kann öfters draufklicken um zu testen). Schließt man den FDialog mit dem X so öffnen sich nachher die anderen Dialoge, da dann der modale Dialog nicht mehr blockiert..

Weiß jemand eine Abhilfe?!

Nachtrag: Was mir noch aufgefallen ist, lässt man beim JFrame (Klasse Testor) den foxtrot Weg weg, so kann man einmal einen weiteren Dialog öffnen (also bis Ebene 2). Also scheint dies ein Fehler zwischen der Mischung modaler Dialog und Foxtrot zu sein...


Nachtrag2: Ha, mit ConcurrentWorker klappts doch Man muss halt nur die Doc gscheit durchlesen..
Problem ist halt, das beim ConcurrentWorker andere Beispiele angeschnitten werden! Aber da der Prozess ja bis zum Beenden nicht beendet wird, muss ich den ConcurrentWorker nehmen, da der Worker ja alle hintereinander macht, währen der ConcurrentWorker die auch nebeneinander machen kann! (In der Doc wird da ein Bsp mit Abbruchsmöglichkeiten angeschnitten... und nicht mit modalen JDialogs :bae


Fazit: Foxtrot ist super und man sollte (wenn man asynchronus Threading vermeiden will) auf foxtrot setzen!!

 

[AlArenal]

Habe mir den Rest nicht wieter durchgelesen, weil doch gleich im ersten Code-Teil ein Klopper drin war:

Das enablen/dusablen oder onstwas an Swing.-Komponenten basteln hat nichts in einem Foxtrot-Worker-Thread zu suchen! Da hast du Ben in seinem Webcast wohl auch nicht aufmerksam genug auf die Finger geschaut

 

[thE_29]

Naja, es klappt aber

Hat er den gemeint man soll es nicht machen? Und das Problem hatte ja speziell nix mit den enablen/disablen zum tun, da es ohne dem genauso wenig geklappt hat!

Bin gerade dabei auf ConcurrentWorker umzuschalten..

Lies dir beim ersten Beitrag Nachtrag2 durch, dann weißt du warum ich dieses Verhalten habe..


Und damit du und Ben auf mich stolz sein könnt, nehme ich das enablen von den Comps aus dem foxtrot raus und baue es vorher und nachher ein

 

[thE_29]

Hier noch die ausgebesserte Version von meinem Bsp

public class Testor extends JFrame
{
  private static class FDialog extends JDialog
  {
    private static int dlgCounter = 1;
    public FDialog(int dlgCount, JFrame owner)
    {
      super(owner, "Dialog " + dlgCount + "  Insgesamt: " + dlgCounter, true);
      init(dlgCount);
    }
    
    public FDialog(int dlgCount, JDialog owner)
    {
      super(owner, "Dialog " + dlgCount + "  Insgesamt: " + dlgCounter, true);
      init(dlgCount);
    }
    
    private void init(final int dlgCount)
    {
      final JButton testButton = new JButton("Hit me " + dlgCount);
      testButton.addMouseListener(new MouseAdapter() {
        public void mousePressed(MouseEvent e)
        {
          testButton.setEnabled(false);
          try{
            foxtrot.ConcurrentWorker.post(new foxtrot.Job()
            {
              public Object run()
              {
                FDialog dlg = new FDialog(dlgCount + 1, FDialog.this);
                dlg.setVisible(true);
                return null;
              }
            });
          }
          catch(Exception ex)
          {
            ex.printStackTrace(System.out);
          }
          testButton.setEnabled(true);
        }
      });
      dlgCounter++;
      this.getContentPane().add(testButton);
      this.setSize(200 + (dlgCount * 10),200 + (dlgCount * 10));
      this.setLocationRelativeTo(getParent());
    }
  }

  public Testor() throws Exception
  {
    super();
    final JButton testButton = new JButton("Hit me");
    testButton.addMouseListener(new MouseAdapter() {
      public void mousePressed(MouseEvent e)
      {
        testButton.setEnabled(false);
        try{
          foxtrot.ConcurrentWorker.post(new foxtrot.Job()
          {
            public Object run()
            {
              FDialog dlg = new FDialog(1, Testor.this);
              dlg.setVisible(true);
              return null;
            }
          });
        }
        catch(Exception ex)
        {
          ex.printStackTrace(System.out);
        }
        testButton.setEnabled(true);
      }
    });
    this.getContentPane().add(testButton);
    this.setSize(300,300);
    this.setLocationRelativeTo(getParent());
    this.setVisible(true);
  }
}

Wo schön brav außerhalb des Foxtrot Workers die Komponenten verändert werden

 

[AlArenal]

Er muss nicht meinen, dass man es nicht machen sollte. Wer sich mit Swing beschäftigt weiß, dass die wenigsten UI-Operationen in einem anderen als dem AWT Event Dispatcher Thread laufen dürfen und das die Seiteneffekte wie beim Multithreading üblich nicht absehbar sind.

Darüber hinaus sagt einem das die Logik, denn der Sinn von Foxtrot & Co. ist es zeitaufwändige Operationen aus dem EDT auszulagern, um diesen nicht zu sperren. Der Sinn ist nicht nun alles erdenkliche an Kleinkram auch noch auszulagern.

Ich habe hier diverse Anwendugnen problemlos nachträglich auf Foxtrot umgestellt, da meine Events u.a. umfangreichee Rechenarbeiten, lesen/schreiben von Dateien (XML), und diverse Anfragen über XML-RPC an die Server beinhalten. Bei mir friert diesbezüglich in im GUI nichts mehr ein oder wird nicht mehr neu gezeichnet und die User haben während dem Ablauf der Hintergrundthreads auch Info darüber, dass die Anwendung etwas tut. Wenn ich beispielsweise eine JList aktualisiere und dazu im Hintergrund Daten vom Server ziehe, setze ich so lange ein Model, dass dem User einen Text á la "Lese Daten..." anzeigt. Meist sieht man den nicht, weils schnell genug geht, aber in anderen Netzwerken, bei hoher Serverauslastung oder übers Internet, kann das schon anders aussehen.

Das einzige Problem dass ich mit Foxtrot habe ist, dass es nichts ebenso kinderleichtes für die allgemeine Verwendung gibt. Foxtrot-Threads können nur aus dem EDT gestartet werden....

 

[AlArenal]

In deinem letzten Beispiel erschließt sich mir der Sinn nicht. Das Öffnen einen neuen JFrame hat doch auch nichts in einem Foxtrot Worker Thread zu suchen....

 

[thE_29]

Das öffnen ist ja auch nur ein Bsp!

Bei mir ist es immer so, dass das öffnen eines JDialogs/JFrame die arbeit die dahinter steckt auch gemacht wird!

Zb soll ein Fenster mit 120 Tabellen Inhalten angezeigt werden! Man klickt auf den Button und dann soll der JDialog mit dem Inhalt angezeigt werden (ohne das die GUI blockiert). Und da nehme ich das, damit es nicht so aussieht als ob alles einfriert!

Das Anzeigen hier ist nur als Anschaungsbsp da (da dahinter ja keine starke Rechenleistung steckt)!

 

[thE_29]

Hui.. jetzt habe ich das Problem was du angeschnitten hast!

Ich habe nen schließen Button welcher die gleiche Methode aufruft wie das X beim beenden des Dialoges!

Klicke ich auf den Button, so wird (durch meinen Listener oben) das ganze ja schon in nem foxtrot Thread ausgeführt!

Drücke ich hingegen auf das X so wird das ja im EDT ausgeführt! So nun muss ich in der Methode onClose rausfinden welcher Thread ich bin, denn ich will das da jedes mal System.gc() aufgerufen wird da mir sonst mal der Speicher ausgeht..

Aber zum Glück gibts ja die Methode: SwingUtilities.isEventDispatchThread() wo man unterscheiden kann

 

[AlArenal]

Um so nen Muckefuck bin ich bisher noch rumgekommen, weil ich keinen Swing-Kram in meine Foxtrrot-Threads packe. Wenn ich mir solche Probleme also gar nicht erst mache, muss ich sie später auch nicht lösen

 

[thE_29]

Naja, ich will ja den Listener einmal so machen (also via foxtrot)

Und da der Listener ja nicht wissen kann was du in der invoke Methode machst, kann ich da auch nicht drauf eingehen ob das jetzt nur Rechendinge sind oder eben zB nur mal einen Dialog anzeigen!

Wahrscheinlich werde ich mir einfach beim Listener ne Add Methode schreiben die eben dann explizit foxtrot nutzt, da es zu 80% sich wirklich nur ums Anzeigen handelt (also auf was der Listener reagiert).

 

[AlArenal]

Ich kann dir gerade nicht folgen. Kann aber auch an meiner Migräne liegen.

 

[thE_29]

Naja, das ganze Problem bezog sich auf meinen Listener! (mein erstes Codestück im 1. Post)

Ich habe mir nen eigenen Listener geschrieben der eben auf div. Maus und KeyEvents reagiert (je nach addListener Methode).

Im Listener wird dann die Methode invoke(AWTEvent e) aufgerufen! Welche eben in den jeweiligen Klassen ausimplentiert ist! (so wie actionPerformed, etc..)

So nun wollte ich im Listener gleich sagen, er soll es (die Methode invoke) via foxtrot aufrufen um Freezer in der GUI zu verhindern!

Nun da ich im Listener ja net weiß was hinter der Methode invoke ist (kann ja Dialog anzeigen, irgendwas rechnen, etc. sein) ist, gabs da eben dieses Problem mit dem modalen JDialog!

Und von daher mache ich wieder ne neue addListener Methode welche den foxtrot einhängt und bei dem Stanard nehme ich ohne foxtrot (weil wenn dahinter nur ein Dialog aufpopt brauche ich da net wirklich foxtrot).

Hoffe du konntest mir jetzt folgen

 

[AlArenal]

Jau, jetzt hab ichs glaub ich verstanden.
Frische Luft beinm Gang zum Bäcker wirkt Wunder, auch wenn ich immernoch Schlagseite habe