JTable erst nach Änderung der Spaltenbreite neu zeichnen

[tomse]

Hallo,

ich habe eine JTable der ich für einige Spalten ein JTextPane als cell renderer zugewiesen habe, um formatierten bzw. mehrzeiligen Text anzuzeigen.
Damit das ganze funktioniert, wird beim neuzeichnen (Aufruf von TableCellRenderer.getTableCellRendererComponent(...)) die Höhe der Zeile berechnet, in der sich die neu zu zeichnende Zelle befindet. Die Höhe der einzelnen Zelle (mit JTextPane renderer) wird dabei über die getPreferredSize().height eines separaten JTextPanes berechnet.

Und jetzt zur eigentlichen Frage:
Beim Ändern der Spaltenbreite durch den User kann man bei langsameren Systemen zugucken, wie die Tabelle neu gezeichnet wird. Gibt es für JTable irgendeine Option um das neuberechnen solange herraus zu zögern, bis die Maustaste wieder losgelassen wurde?

 

[Michael...]

Wo setzt Du denn die Zeilenhöhe? Etwa in der Methode getTableCellRendererComponent() Deines Renderers?

 

[tomse]

Genau. In getTableCellRendererComponent laufe ich über alle Spalten in der zu aktualisierenden Zeile und bilde das Maximum der Zeilenhöhe und setze sie mittels table.setRowHeight.

So wie es aussieht, ist die seitaufwendige Aktion das Formatieren des Textes um die Höhe des JTextPanes zu berechnen.
Da sich beim Ändern der Tabellengrösse der Inhalt ja nich ändert, wäre mein Problem auch zu lösen, wenn ich an den bereits formatierten Text (Document) der Zellen wieder rankommen würde. Zusätzlich bräuchte ich natürlich noch die Information, warum die Zelle neu berechnet werden soll, also inhaltliche Änderung oder nur resize...

 

[Michael...]

ein setzen der Zeilenhöhe in der Methode bewirkt ein repaint der Tabelle, das bewirkt wiederum einen Aufruf der getTableCellRendererComponent() Methoden der Renderer usw.
Kurzum damit wird eine Endlosschleife ausgelöst
Das setzen der Zeilenhöhe sollte daher ausserhalb der Renderermethode implementiert werden.

 

[tomse]

Ich setze die Zeilenhöhe nur neu, wenn sie sich geändert hat.
Aber versuchsweise hab ich die Code-Zeile (setzen der Höhe) mal auskommentiert um zu sehen, ob was zuoft gemacht wird, aber mit und ohne dem Neusetzen der Zeilenhöhe wird der TableCellRenderer genausooft gerufen.
Das mit der (möglichen) Endlosschleife kann ich also so nicht nachvollziehen...

 

[Ebenius]

Das ist ganz schön ekelig. Ich würde dazu von der JTable ableiten, doLayout() überschreiben und dort die Berechnung durchführen. Außerdem muss die Tabelle ihre eigene Zeilenhöhe überprüfen, wenn sich die Daten ändern. Sowas in etwa:

    final JTable table = new JTable(2, 2) {

      /**
       * Adjusts the row height. Uses the maximum preferred height of all
       * cells rendered.
       * <p>
       * TODO: Implement the mechanism to request renderer's preferred cell
       * height with fixed width given.
       */
      protected void adjustAutoRowHeight() {
        final int rowCount = getRowCount();
        final int columnCount = getColumnCount();
        int newRowHeight = 25;
        for (int row = 0; row < rowCount; row++) {
          for (int column = 0; column < columnCount; column++) {
            final Component rendererComponent =
                  prepareRenderer(getCellRenderer(row, column), row, column);
            // adjust maxRowHeight based on renderer content
          }
        }

        final int oldRowHeight = getRowHeight();
        setRowHeight(newRowHeight);
        if (oldRowHeight != newRowHeight && EventQueue.isDispatchThread()) {
          // If the method is called within a layout cycle, we need to revalidate again :-(
          SwingUtilities.invokeLater(new Runnable() {

            public void run() {
              resizeAndRepaint();
            }
          });
        }
      }

      @Override
      public void doLayout() {
        super.doLayout();
        final JTableHeader tableHeader = getTableHeader();
        TableColumn resizingColumn =
              tableHeader != null ? tableHeader.getResizingColumn() : null;
        TableColumn draggedColumn =
              tableHeader != null ? tableHeader.getDraggedColumn() : null;

        if (resizingColumn == null && draggedColumn) {
          adjustAutoRowHeight();
        }
      }

      @Override
      public void tableChanged(TableModelEvent e) {
        super.tableChanged(e);
        if (e != null
              && e.getFirstRow() != TableModelEvent.HEADER_ROW
              && (e.getType() != TableModelEvent.UPDATE || e.getLastRow() != Integer.MAX_VALUE)) {
          // in all other cases, super implementation calls resizeAndRepaint()
          // which triggers doLayout
          adjustAutoRowHeight();
        }
      }
    };

Allerdings sollte das das Problem noch nicht ganz lösen. Der TableHeader sagt einem leider nicht Bescheid, wenn man die zu verschiebende Spalte los lässt. Dazu kann man den TableHeader erweitern:

    final JTableHeader tweakingTableHeader = new JTableHeader(table.getColumnModel()) {

      private static final long serialVersionUID = 1L;

      @Override
      public void setResizingColumn(TableColumn aColumn) {
        super.setResizingColumn(aColumn);
        final JTable table = getTable();
        if (aColumn == null && table != null) {
          table.revalidate();
        }
      }
    };
    table.setTableHeader(tweakingTableHeader);

Wenn der TableCellRenderer auf Grund der Komplexität trotzdem noch zu langsam ist, dann kann man dort auch noch tricksen, indem man einen anderen Zelleninhalt darstellt, während eine Spalte verschoben/vergrößert/verkleinert wird:

  private static class TweakingCellRenderer extends DefaultTableCellRenderer {

    private static final long serialVersionUID = 1L;

    private final TableCellRenderer slowRenderer;

    TweakingCellRenderer(TableCellRenderer slowRenderer) {
      this.slowRenderer = slowRenderer;
    }

    @Override
    public Component getTableCellRendererComponent(
          JTable table,
          Object value,
          boolean isSelected,
          boolean hasFocus,
          int row,
          int column) {
      final JTableHeader header = table.getTableHeader();
      if (header != null && header.getResizingColumn() != null) {
        value = "Resizing...";
        setBackground(Color.YELLOW);
      } else if (header != null && header.getDraggedColumn() != null) {
        value = "Moving...";
        setBackground(Color.YELLOW);
      } else {
        return slowRenderer.getTableCellRendererComponent(table, value,
              isSelected, hasFocus, row, column);
      }

      return super.getTableCellRendererComponent(table, value, isSelected,
            hasFocus, row, column);
    }
  }

    final TableCellRenderer tweakingRenderer =
          new TweakingCellRenderer(new DefaultTableCellRenderer());
    table.setDefaultRenderer(Object.class, theSlowAndComplexRenderer);

Ich hoffe, das hilft weiter.

Kurzum damit wird eine Endlosschleife ausgelöst

Nö. Dadurch gibt's nur eine Endlosschleife, wenn sich die Zeilenhöhe jedes mal ändert. [c]setRowHeight(int)[/c] tut nix, wenn sich die Zeilenhöhe nicht verändert. Das ändert aber nix daran, dass der TableCellRenderer die Tabelle nicht verändern sollte, weil ihm das einfach nicht zusteht.

Ebenius

 

[tomse]

Vielen Dank erstmal euch beiden!

@Ebenius
Ich hab mal deinen code dahingehend modifizert, dass ich mich beim ersten Aufruf mit einem MouseListener in den TableHeader einklinke, und beim loslassen der MausTaste nochmal das Neuzeichnen der Tabelle anstosse (allerdings mit fireTableDataChanged(); ein einfaches revalidate() funktioniert bei mir nicht - hab noch nicht weiter nach der Ursache gesucht)

Ansonsten setze ich den Text einfach erstmal so, wie er kommt, der wird dann während des resizes ggf. erstmal abgeschnitten und die neue Höhe wird nach dem loslassen der Maustaste berechnet.

Ist vielleicht noch nicht ganz optimal, aber auf jeden Fall schon mal ein brauchbarer Ansatz...

Vielen Dank!

Und hier nochmal wie's jetzt ungefähr aussieht (bischen abgespeckt):

private static class MyCellRenderer extends JTextPane implements TableCellRenderer {
  private boolean firstCall = true;
 
    @Override
    public Component getTableCellRendererComponent(
          JTable table,
          Object value,
          boolean isSelected,
          boolean hasFocus,
          int row,
          int column) {

      final JTableHeader header = table.getTableHeader();
      if (firstCall) {
        final JTable t = table;
        header.addMouseListener(new MouseAdapter() {
          @Override
          public void mouseReleased(MouseEvent arg0) {
            AbstractTableModel d = (AbstractTableModel)t.getModel();
            d.fireTableDataChanged();
        }
      });
      firstCall = false;
    }

    setText((String)value);

      if (header != null && header.getResizingColumn() != null) {
        setBackground(Color.YELLOW);
      } else if (header != null && header.getDraggedColumn() != null) {
        setBackground(Color.YELLOW);
      } else {
        // calculate row height and set new height if necessary
      }
 
      return this;
    }
  }

 

[Ebenius]

Ne, da haste irgendwie was falsch verstanden. Auf keinen Fall sollte ein TableCellRenderer Listener eines JTableHeader sein. Das ist Schweinkram, sorry. ;-)

Ebenius

 

[tomse]

[...] Auf keinen Fall sollte ein TableCellRenderer Listener eines JTableHeader sein. Das ist Schweinkram, sorry. ;-)

Die Aussage ist erstmal sehr pauschal - kannst du das irgendwie konkretisieren?

Den Vorteil, den ich an der Lösung mit dem MouseListener sehe ist der, dass der TableCellRenderer als eigenständige Komponente benutzt werden kann. Bei deiner Lösung sind beide Teile getrennt, also wenn man den TableCellRenderer ohne den modifizerten Header benutzt funktioniert das Ganze nicht mehr. Ausserdem erscheint mir das mit dem Listener simpler zu sein (keep it simple...) - oder nicht?

 

[Ebenius]

Ein CellRenderer hat eine Aufgabe: Er initialisiert einer Komponente mit der eine Zelle gezeichnet werden kann. Renderer sind immer passiv. Sie steuern niemals.

Den Vorteil, den ich an der Lösung mit dem MouseListener sehe ist der, dass der TableCellRenderer als eigenständige Komponente benutzt werden kann. Bei deiner Lösung sind beide Teile getrennt, also wenn man den TableCellRenderer ohne den modifizerten Header benutzt funktioniert das Ganze nicht mehr. Ausserdem erscheint mir das mit dem Listener simpler zu sein (keep it simple...) - oder nicht?

Abgesehen davon, dass dieser CellRenderer Dinge tut die er nicht tun sollte (Verhalten der Tabelle steuern, Modell-Ereignisse fälschen), folgende Fragen: Wer entfernt den CellRenderer als MouseListener vom JTableHeader, wenn ich den Header austausche? Wer fügt den CellRenderer wieder als MouseListener zum neuen JTableHeader hinzu? Wer entfernt den CellRenderer als MouseListener vom JTableHeader, wenn ich den Renderer nicht mehr benötige (und der Garbage Collector in aufräumen könnte, wenn er nicht am JTableHeader dranhinge)? Wie sorgt der CellRenderer dafür, dass er in einer zweiten Tabelleninstanz ebenso funktioniert ([c]first[/c] wird ja nur einmal auf [c]false[/c] gesetzt)? Eben.

Ebenius

 

[tomse]

Abgesehen davon, dass dieser CellRenderer Dinge tut die er nicht tun sollte (Verhalten der Tabelle steuern, Modell-Ereignisse fälschen), folgende Fragen: Wer entfernt den CellRenderer als MouseListener vom JTableHeader, wenn ich den Header austausche? Wer fügt den CellRenderer [...]

OK, alles keine unlösbaren Aufgaben, aber ich geb dir Recht, die Lösung ist nicht ganz rund und das "single responsibility" Argument überzeugt mich dann doch...