Swing 1spaltige JTable ohne Header

[Camino]

Hallo,

da ich letztens vergeblich versucht hatte, ein Calc-Dokument (OpenOffice) in meine Swing-Anwendung einzubinden, bin ich nun dabei, dieses Calc-Dokument in Swing als Formular nachzubauen. Dazu verwende ich ein GridBagLayout auf einem JPanel. Die meisten Komponenten sind auch relativ einfach dort zu erstellen und anzuordnen. Probleme hab ich noch bei einer Komponenten: und zwar gibt es ja bei Calc- bzw. auch Excel-Dokumenten Zellen, die einen Rahmen haben können und in die man Werte eingeben kann (wie bei einem Formular). Dies möchte ich nun in Swing nachbauen. Zuerst hatte ich JTextField genommen und einen Rahmen mit 1 px drumherum gesetzt. Das geht bei einzelligen Feldern. Jetzt hab ich aber in dem Calc-Dokument z.B. 10 Eingabefelder (Zellen), die untereinander liegen und mit Rahmen (Gitternetzlinien) vesehen sind. Da dachte ich mir, das sieht eigentlich aus, wie eine einspaltige Tabelle ohne TableHeader und mit einem Rahmen von 1 px um die Tabellenzellen herum. Jetzt ist meine Frage, wie kann ich solch eine JTable ohne Header mit einer Spalte und 10 Zeilen mit Rahmen um alle Zellen erzeugen? In diese Zellen sollten dann (wie bei einem Calc-Dokument) Werte eingegeben werden können, die dann unterhalb der Zellen zusammengezählt werden. Oder gibt es noch eine andere Möglichkeit, wie ich so eine gewünschte Komponente erzeugen kann? Ich steh gerade ein wenig auf dem Schlauch und bräuchte mal ein paar Tipps...

Danke
Camino

 

[KrokoDiehl]

Also ob es ne Alternative gibt, kann ich dir so nicht sagen, aber eine ein-spaltige Tabelle ist per se kein Problem:
Du brauchst zB ein TableModel das bei

getColumnCount()

1 zurück liefert.
Dann kannst du bei der Tabelle folgende Methoden benutzen, damit dass Aussehen wie gewünscht wird (zur Not: Eigenen Renderer machen):

JTable table = ...;
table.setShowGrid(true);
table.setGridColor(Color.black);
table.setIntercellSpacing(new Dimension(1, 1));
table.setTableHeader(null); // damit hat sie keine Spaltenköpfe

 

[Camino]

Hallo,

das mit dem Tipp mit einem TableModel ist echt prima. So kann ich die Spalten auf 1 und die Zeilen auf die gewünschte Zellenanzahl setzen. Spaltenköpfe hab ich auch keine.

Was nicht so klappt, ist das mit der Umrandung. Ich hab bei den Zellen der Tabelle nur rechts und unten den schwarzen Rahmen. Die oberste Zelle hat oben keinen Rahmen und alle Zellen haben links keinen Rahmen. Keine Ahnung, ob das vielleicht auch was mit dem GridBagLayout zu tun hat. Oder mit dem Look&Feel...

Ich hab nämlich als Look&Feel Nimbus eingestellt, wodurch die Tabellen etwas anders aussehen, als bei den anderen L&F. Ich glaube ohne Nimbus sind sowieso Rahmen um dieTabellenzellen. Bei Nimbus hab ich abwechselnde Hintergrundfarben bei den Zellen, aber keinen Rahmen.

Vielleicht werde ich auch noch einen eigenen Renderer für die Tabelle schreiben. Ich muss wohl auch noch die Zeilenhöhe irgendwo festlegen.

Gruss
Camino

 

[Michael...]

Eine JTable mit einer Spalte und ohne Header ist doch quasi eine JList!?!
Das Aussehen der Zellen (z.B. Rahmen) kann man per Renderer beeinflussen

 

[Camino]

Eine JTable mit einer Spalte und ohne Header ist doch quasi eine JList!?!
Das Aussehen der Zellen (z.B. Rahmen) kann man per Renderer beeinflussen

Hmm, aber ich möchte in dieser "Liste" ja auch Eingaben ermöglichen, also wie bei Zellen in einem Calc-Dokument. Und es soll unterhalb dieser Spalte ein Feld sein, welches die Einträge (z.B. Zahlen oder Geldbeträge) zusammengezählt werden. Keine Ahnung, ob das mit JList so möglich ist. Da kommt mir die einspaltige JTable eher geeignet dafür vor. Ich kann mich da aber auch täuschen...

 

[Michael...]

Ah, OK. Das mit dem Editieren hatte ich nicht gesehen. Dann ist die JTable wohl doch besser geeignet.
Aber auch hier kann man das Aussehen der Zellen per Renderer (TableCellRenderer) beeinflussen

 

[Camino]

Ich weiss jetzt garnicht, ob ich überhaupt einen CellRenderer brauche. Eigentlich müsste mein Ziel ja auch mit den oben genannten Methoden der JTable hinzukriegen sein (setShowGrid, setGridColor, setIntercellSpacing, setTableHeader). Aber irgendwie wird das Grid (Gitternetzlinien) nicht komplett gezeichnet. Wie schon gesagt, es fehlt auf der linken Seite sowie oben bei der ersten Zelle. Ich hab auch mal bei setIntercellSpacing die Werte auf (2,2) gesetzt, aber das ändert auch nichts.

 

[Camino]

Also, auch wenn ich mehrere Spalten anzeige, es fehlt beim Grid immer die Linie ganz links und ganz oben. Auch wenn ich z.B. nur vertikale Gridlinien nehme. Und ich hab auch schon getestet, die Tabelle in der Mitte der Zelle des GridBagLayouts anzuordnen. Die Linien links und oben fehlen trotzdem weiterhin...

 

[Camino]

Hmmm, es scheint wirklich so zu sein, dass die Gridlinien die erste vertikale Linie und di eoberste horizontale Linie nicht mitzeichnen. Das fällt wahrscheinlich nicht so schnell auf, weil die Tabellen meistens in einem JScrollPane liegen und dies ja aussenherum einen Rahmen hat. Ich hatte im Internet gerade eben ein Beispiel gefunden, bei dem die Gitternetzlinien rot eingefärbt waren und man bei der Tabelle in einem Scrollpane genau sehen konnte, dass die roten Linien ganz links und ganz oben gefehlt hatten. Keine Ahnung, warum das so ist und ob ich das irgendwie trotzdem hinbekommen kann. Was ich jetzt mal getestet hatte war, der Tabelle einfach einen Border in der gleichen Farbe wie der des Grids zu verpassen. Dann sieht es so aus, wie ich es haben wollte.

 

[Camino]

Jetzt muss ich wohl nur noch eine Möglichkeit finden, dass die eingegebenen Daten auch in den Zellen bleiben. Im Moment ist es nämlich so, dass ich etwas eingeben kann (hab im TableModel isCellEditable auf true gesetzt), aber sobald ich wieder aus der Zelle rausgehe, mit Enter-Taste oder Pfeiltasten, dann ist der eingegebene Wert wieder verschwunden. Muss ich dafür nun im TableModel eine Collection oder ein 2-dimensionales Array anlegen, in welchem die Daten festgehalten werden? Ich brauch die Daten dort nur solange das JPanel angezeigt wird. Es wird nur etwas berechnet und evtl. ausgedruckt, und danach wieder geschlossen.

 

[KrokoDiehl]

In deinem TableModel gibt es die Methode

setValueAt()

, die musst du entsprechend implementieren, sodass der übergebene Wert in deine Daten kommt, die du mit

getValueAt()

ausliest.

 

[Camino]

OK, danke für den Hinweis. Ich hatte bisher in Tabellen immer nur Daten dargestelt und die Änderung über Dialoge gemacht. Das mit dem setValueAt() klappt jetzt jedenfalls. Ich hab auch einen TableCellRenderer geschrieben, damit die Einträge rechts ausgerichtet werden. Mein Ziel ist es ja, dass ich mit dieser Tabelle Geldbeträge eingeben kann und diese dann unter der Tabelle als Summe angezeigt werden, so ähnlich eben wie bei Calc bzw. Excel.

Ich hab in dem TableModel ein normales Array genommen, und kein zweidimensionales, da ich ja sowieso immer nur 1 Spalte habe. Ich denke auch nicht, dass es für mich ein Problem ist, die Werte innerhalb dieses Array zusammenzuzählen. Mein Problem wird wohl nur sein, wie zeige ich immer die aktuellen Summe an. Ich muss die Summe ja nach jeder Eingabe/Änderung in der Tabelle aktualisieren. Das kann sowohl nach Drücken der Enter-Taste, der Tab-Taste oder der Pfeiltasten passieren. Das heisst ich müsste nach dem Fokusverlust einer Zelle die Ausgabe der Summe aktualisieren. Da gibt es bestimmt einen Fokus-Listener...?

Bezügl. den Geldbeträgen hatte ich gelesen, dass es besser wäre, dafür BigDecimal zu nehmen. Ist das so richtig?

 

[KrokoDiehl]

Die Summe die du anzeigen möchtest ist die Summe über das Array? Oder kann sie auch von außerhalb beeinflusst werden?
In ersterem Fall könntest du an deine Tabelle eine zusätzliche Zeile anfügen, die die Summe darstellt und dein TableModel am besten von AbstractTableModel erben, etwa so:

class MyTableModel extends AbstractTableModel
{
    private int[] tableData = ...;

    ...

    public int getRowCount()
    {
        return tableData.length + 1; // +1 für Summe
    }

    public Object getValueAt(int row, int col)
    {
        if (row == this.getRowCount()-1)
            return /*Summe vom Array*/;
        else
            return tableData[row];
    } 

    public boolean isCellEditable(int row, int col)
    {
        return (row < this.getRowCount()-1); //sprich alles außer letzter Zeile
    }

    public void setValueAt(Object val, int row, int col)
    {
        tableData[row] = /* val to integer */;

        // das ist nun wichtig: Wann immer sich was an der Tabelle ändert,
        // wird ausgelöst, dass auch die letzte Zeile (die Summe) neu
        // dargestellt wird. So ist der Inhalt immer up-to-date
        this.fireTableCellUpdated( this.getRowCount()-1, 0 );
    }
}

Wie in dem Bsp (grob) beschrieben würde ich es machen. Wenn sich deine Summe auch nach anderen Änderungen verändern kann, musst du dieses

fireTableCellUpdated()

entsprechend aufrufen. Das sorgt im Prinzip dafür, dass die genannte Zelle neu gezeichnet wird (natürlich muss dann auch der neue Summenwert zur Verfügung stehen).
Natürlich gibt es bei einer solchen Methodik weitere Probleme, z.B. wenn deine Tabelle sortierbar ist, oder dass du den Renderer entsprechend anpassen musst, weil die Summen-Zelle per se genauso aussieht.
Wenn du stattdessen ein Label unterhalb (oder sonstwo) deiner Tabelle hast, wäre das einfachste, dessen

setText()

-Methode aufzurufen, wann immer sich ein Summand ändert (zB in

setValueAt()

).
Die völlig saubere Methode wäre aber, dass der Label, bzw. derjenige, der den Label verwaltet, sich als TableModelListener an dein Tabellenmodell hängt und eben auf das entsprechende update-Ereignis reagiert.

Fazit: Ich würde hier nicht über einen FocusListener gehen, zumindest nicht, wenn sich die Summe nur aus der Tabelle heraus aufbaut.

Zur Sache mit BigDecimal ... tja, wie hoch sollen die Geldbeträge denn sein? Im Grunde würde auch ein double reichen. Selbst der hat schon genug Stellen, um Deutschlands Schulden darzustellen
Oder anders gesagt: Ich habe noch nicht gehört, dass man für Geldbeträge eher BigDecimal nehmen sollte. Aber das muss nichts heißen.
Was eher eine Überlegung wäre (...für den Renderer...) ein

NumberFormat.getCurrencyInstance()

zum Darstellen der Geldbeträge zu nehmen.

 

[Camino]

Hallo,

danke für diese Tipps. Es werden nur die Werte zusammengezählt, die in diese Tabelle eingegeben werden. Also eigentlich die Summe der Werte in dem Array. Gut, diese Summe muss dann später noch woanders hingeschrieben werden, aber das ist dann ja auch nicht mehr so problematisch. Die Idee, das in der setValue-Methode des TableModel zu veranlassen, ist prima. Weil dort ja alle Änderungen an der Tabelle drüberlaufen. Ich werde das gleich mal probieren...

Ich muss auch noch überlegen, ob ich das Feld für die Summe in die Tabelle aufnehme oder als JLabel unterhalb der Tabelle dranhänge. Am besten baue ich mir ein Klasse, in der alles drin ist, die auch Parameter übernimmt (z.B. wieviele Zeilen benötigt werden), dann kann ich diese Komponente flexibel einsetzen.

Das mit dem BigDecimal hatte ich im Internet gelesen. Es ging da aber wohl auch nicht nur um die Grösse der Geldbeträge, sondern auch um die Genauigkeit. Es hatte jemand gemeint, double und float wären beim Rechnen (und Runden) bei Geldbeträgen unbrauchbar, und BigDecimal wäre besser. Bei mir werden die Geldbeträge jetzt auch nicht so dermassen hoch sein, ich wollte nur sichergehen, dass das Rechnen mit den Beträgen möglichst genau läuft. Aber vielleicht schau ich mir das erstmal mit double an...

Das mit dem NumberFormat.getCurrencyInstance() hab ich im Internet auch schon gesehen. Hört sich gut an, da auch gleich schon das Währungssymbol mit drangehängt wird. Werde ich mir mal genauer anschauen...

Danke nochmal für die Hilfe...

Gruss
Camino

 

[Camino]

OK, hab das gerade mal getestet. Und es ist so, wie ich irgendwo im Internet in einem Forum gelesen hatte:
Ich hab die Double-Werte 5.15 und 23.4 eingegeben und addiert. Als Summe kam 28.549999999999997 raus, anstatt 28.55. OK, das lässt sich ja auch wieder aufrunden. Geht wohl auch mit dem NumberFormat. Aber irgendwie ist das nicht so ganz optimal...

 

[Camino]

Desweiteren sind mir noch ein paar Baustellen aufgefallen:

- Ich muss wohl die Eingabemöglichkeit der Beträge einschränken. Es dürfen nur Beträge mit maximal 2 Nachkommastellen eingegeben werden. Im Moment hab ich noch die Möglichkeit, mehrere Nachkommastellen anzugeben. Dies wird dann durch das NumberFormat zwar auf 2 Stellen nach dem Komma gekürzt und gerundet, aber der Double-Wert mit allen Nachkommastellen wird im Array gespeichert. Muss ich wohl die Eingabemöglichkeit formatieren...

- Da ich im TableModel für die Spalte die Klasse Double angegeben habe, muss ich den Betrag nun mit einem Punkt eingeben. Ein Komma wird nicht akzeptiert. Damit bin ich noch nicht ganz zufrieden.

- Im Moment sind alle Tabellenzellen mit dem Betrag "0,00 €" vorbelegt. Wenn ich den Fokus auf eine Tabellenzelle erhalte (ob durch Mausklick oder Tab/Enter), bleibt der Wert drin stehen und ich muss ihn erst löschen bzw. überschreiben. Besser wäre es vielleicht, wenn mit Fokuserhalt die Zelle geleert wird, oder noch besser der Betrag selektiert wird. Dann kann ich nämlich mit einem Tastendruck den Wert löschen oder mit dem Cursor an die richtige Stelle zum Ändern fahren.

 

[Camino]

OK, ich vermute mal, dass ich nun mit einem TableCellEditor und TableCellRenderer arbeiten muss. Hab bisher aber nur ein Beispiel für Datum-Formate gefunden. Vielleicht schaffe ich es ja, dies für meine Geldbeträge (double) umzuschreiben.

 

[KrokoDiehl]

Japp. Der CellEditor ist hier dein Freund
Du kannst z.B.

stopCellEditing()

überschreiben, sodass es false zurück gibt, wenn der Inhalt nicht passt (quasi das Äquivalent zum InputVerifier).
Ansonsten ist es ganz nett, wenn beim Starten des Editierens einer Zelle der komplette Inhalt direkt selektiert ist. Das Erreicht man z.B. damit, indem man in der

getTableCellEditorComponent()

folgende Zeile einbaut (vorausgesetzt dein Editor ist eine JTextComponent... ):

 //comp ist der TableCellEditor
 ((JTextComponent) comp).selectAll();

Die Tatsache, dass man 10 Nachkommastellen angeben kann, aber nur zwei sieht, ist eine Designfrage. Hier hat man im Grunde ne deutliche Trennung zwischen Daten und Ansicht, denn üblicherweise werden Währungen nur zweistellig nach dem Komma angezeigt. Rechnen kann man aber durchaus mit mehr Stellen.
Wenn du nun rundest, sodass intern auch nur zwei Nachkommastellen existeren, verlierst du natürlich Genauigkeit. Das ist nun eben die Frage, ob diese notwendig ist. Es kann natürlich für den Benutzer verwirrend sein, wenn er 3,4235 eingibt, aber nur 3,42 dasteht.

 

[Camino]

Das mit dem CellEditor werde ich so mal machen und schauen, wie weit ich damit komme.

Bei den Geldbeträgen, die eingegeben werden, brauch ich eigentlich grundsätzlich nur 2 Nachkommastellen. Es werden halt Einkommens- und Kosten-Rechner, von denen mehrere auf einem Blatt angeordnet werden. Die User sollen also nur Geldbeträge, dort eingeben, die am Ende zusammengezählt werden. Da muss ja eigentlich nichts gerundet werden und ich brauch auch nur diese 2 Stellen hinter dem Komma. Das müsste ja evtl. mit dem CellEditor hinzukriegen sein. Dann muss diese Summe nochmal durch 6 geteilt werden, da wird eben dann bei Bedarf gerundet. Ich fands halt etwas seltsam, als ich das Beispiel vorhin gebracht hatte, bei dem ich zwei Zahlen mit einer bzw. zwei Nachkommastellen addiert hatte und dann aber eine Zahl mit total vielen Nachkommastellen rauskam.