[SWING] Spaltenbreite in JTable anpassen
Martin Wronna
Wünsch nen schönen Sonntagmorgen.
Ich lese mir Daten ein, die ich in einer JTable anzeige.
Derzeit verwende ich (nur) DefaultTableColumn und
DefaultTableColumnModel, dadurch setzt die JTable die Spaltenbreite
jeder Spalte defaultmässig auf 75.
Ich habe mir nun eine Methode gebastelt, die diese Breite an die Breite
der Überschrift anpasst.
Dazu berechne ich den Text im ColumnHeader mit der aktuellen
FontMetrics und weise dies dann per setPreferredWidth() der Column zu.
Jetzt fehlt mir allerdings der Durchblick, wo (in welche Klasse,
welcher Methode) baue ich das nun am saubersten ein ?
Ich habs bereits in der getPreferredWidth() in einer abgeleiteten
DefaultTableColumn probiert, aber dann lässt sich die Breite nach
Erzeugen der JTable nichtmehr ändern.
Beim addColumn im TableModel wollt ich auch schon, aber da fehlt mir
irgendwie der Zugriff auf die TableColumn zum setzen.
Irgendwie hab ich mich in den vielen Klassen, die zu einer JTable
gehören, verlaufen und find anscheinend den Wald vor lauter Bäumen
nicht.
Würd mich freuen wenn Ihr mir auf die Sprünge helfen könnt.
Martin
Linda Radecke
Martin Wronna wrote:
> Wünsch nen schönen Sonntagmorgen.
> Ich lese mir Daten ein, die ich in einer JTable anzeige.
> Derzeit verwende ich (nur) DefaultTableColumn und
> DefaultTableColumnModel, dadurch setzt die JTable die Spaltenbreite
> jeder Spalte defaultmässig auf 75.
> Ich habe mir nun eine Methode gebastelt, die diese Breite an die Breite
> der Überschrift anpasst.
An die Ueberschrift? Waere es nicht sinnvoller, es an den
Zelleninhalt anzupassen? (ich frag ja nur...)
> Dazu berechne ich den Text im ColumnHeader mit der aktuellen
> FontMetrics und weise dies dann per setPreferredWidth() der Column zu.
>
> Jetzt fehlt mir allerdings der Durchblick, wo (in welche Klasse,
> welcher Methode) baue ich das nun am saubersten ein ?
> Ich habs bereits in der getPreferredWidth() in einer abgeleiteten
> DefaultTableColumn probiert, aber dann lässt sich die Breite nach
> Erzeugen der JTable nichtmehr ändern.
> Beim addColumn im TableModel wollt ich auch schon, aber da fehlt mir
> irgendwie der Zugriff auf die TableColumn zum setzen.
> Irgendwie hab ich mich in den vielen Klassen, die zu einer JTable
> gehören, verlaufen und find anscheinend den Wald vor lauter Bäumen
> nicht.
> Würd mich freuen wenn Ihr mir auf die Sprünge helfen könnt.
Das hier funktioniert bei mir sehr gut:
http://www.chka.de/swing/table/cell-sizes.html
Linda
--
.-. I hear him, before I go to sleep And focus on the day
( ( that's been. I realise he's there, When I turn the
'-` light off and turn over.
Kate Bush - The Man With The Child In His Eyes
Martin Wronna
>
>
> Martin Wronna wrote:
>
>> Wünsch nen schönen Sonntagmorgen.
>
>> Ich lese mir Daten ein, die ich in einer JTable anzeige.
>> Derzeit verwende ich (nur) DefaultTableColumn und
>> DefaultTableColumnModel, dadurch setzt die JTable die Spaltenbreite
>> jeder Spalte defaultmässig auf 75.
>> Ich habe mir nun eine Methode gebastelt, die diese Breite an die
>> Breite der Überschrift anpasst.
>
> An die Ueberschrift? Waere es nicht sinnvoller, es an den
> Zelleninhalt anzupassen? (ich frag ja nur...)
Jein, im speziellen Fall ist die Überschrift breiter als der
Zelleninhalt.
Nachgelagert plane ich (für Verallgemeinerung), auch MaxWidth zu
setzen, dann auf breitesten Wert in allen Zeilen der Spalte.
Befürchte aber, das dies dann vielleicht zu langsam wird, wenn ich jede
Row durchkaue ?
[...]
>
>> Irgendwie hab ich mich in den vielen Klassen, die zu einer JTable
>> gehören, verlaufen und find anscheinend den Wald vor lauter Bäumen
>> nicht.
>> Würd mich freuen wenn Ihr mir auf die Sprünge helfen könnt.
>
> Das hier funktioniert bei mir sehr gut:
> http://www.chka.de/swing/table/cell-sizes.html
>
So ähnlich siehts bei mir auch aus.
Was mich interessiert, wo bindest Du diese Methode ein und wo/wer ruft
die Methode auf ?
Ich hatte eigentlich gedacht, dieses setzen der PreferredWidth direkt
in einer dieser entsprechenden getter- oder setter-Methoden zu tun ?
>
> Linda
Martin
Markus Blatt
> Linda Radecke wrote:
>
> >
> >
> > Martin Wronna wrote:
> >
> >> Ich habe mir nun eine Methode gebastelt, die diese Breite an die
> >> Breite der Überschrift anpasst.
>
> Nachgelagert plane ich (für Verallgemeinerung), auch MaxWidth zu
> setzen, dann auf breitesten Wert in allen Zeilen der Spalte.
> Befürchte aber, das dies dann vielleicht zu langsam wird, wenn ich jede
> Row durchkaue ?
>
Also bei mir klappt das, allerdings ist die Tabelle auch sehr klein.
>
> [...]
> > Das hier funktioniert bei mir sehr gut:
> > http://www.chka.de/swing/table/cell-sizes.html
> >
>
>
> So ähnlich siehts bei mir auch aus.
> Was mich interessiert, wo bindest Du diese Methode ein und wo/wer ruft
> die Methode auf ?
>
Ohne jetzt Lindas Beispiel angeschaut zu haben. Ich mache das einem
TableModelModelListener in der Methode tableModelChanged(TableEvent
e). ColumnResizer ist wie der Name sagt fuer das Setzen der Groesse
zustaendig.
public void tableChanged(TableModelEvent e){
super.tableChanged(e);
if(e.getType()==TableModelEvent.UPDATE){
int col = convertColumnIndexToView(e.getColumn());
if (col>=0) {
if(columnResizer != null)
columnResizer.resizeColumn(col);
}
}
}
Gruss,
Markus
--
Homepage von d(e).c(omp).l(ang).j(ava): http://www.dclj.de
Java-FAQ: http://de.geocities.com/uweplonus/faq/
Aljoscha Rittner
> Linda Radecke wrote:
>
>>
>>
>> Martin Wronna wrote:
>>
>>> Wünsch nen schönen Sonntagmorgen.
>>
>>> Ich lese mir Daten ein, die ich in einer JTable anzeige.
>>> Derzeit verwende ich (nur) DefaultTableColumn und
>>> DefaultTableColumnModel, dadurch setzt die JTable die Spaltenbreite
>>> jeder Spalte defaultmässig auf 75.
>>> Ich habe mir nun eine Methode gebastelt, die diese Breite an die
>>> Breite der Überschrift anpasst.
>>
>> An die Ueberschrift? Waere es nicht sinnvoller, es an den
>> Zelleninhalt anzupassen? (ich frag ja nur...)
>
>
> Jein, im speziellen Fall ist die Überschrift breiter als der
> Zelleninhalt.
> Nachgelagert plane ich (für Verallgemeinerung), auch MaxWidth zu
> setzen, dann auf breitesten Wert in allen Zeilen der Spalte.
Ich mache es so, dass ich Header *und* Zellen betrachte. Dann ist es
gleich, wer breiter ist.
> Befürchte aber, das dies dann vielleicht zu langsam wird, wenn ich jede
> Row durchkaue ?
Im Prinzip kann es zum Performance-Problem kommen. Wenn man nach jedem
insertRow ein Update macht, wird allein bei über 200 Zeilen der
Benutzer merkliche Verzögerungen feststellen. Leider existiert im
Default* Tabellen Modell kein insertRows (für mehrere Zeilen
gleichzeitig), die mußt du dir selber basteln (ist ja nicht
schwierig). Danach solltest du per fireTableRowsInserted erst die
Nachricht abschicken, dass sich etwas geändert hat.
Die Spaltenbreiten werden dann bei mir in einer abgeleiteten Klasse
von JTable in tableChanged berechnet.
Gruß,
Josch.
--
AFAIR ist "Liebfraunmilch" aufgrund des Weingesetzes ein süßlicher
Flüssigklebstoff, den man zu überteuerten Preisen an Touristen verkauft,
und den man nur kraft Gesetzes als Wein ansehen muß.
(Tobias Nüssel in dsrm) Ganz großes ACK.
Martin Wronna
... tableChanged() der JTable ...
Gleich mal ausprobieren
Martin
Linda Radecke
Martin Wronna wrote:
> Linda Radecke wrote:
[...]
> Jein, im speziellen Fall ist die Überschrift breiter als der
> Zelleninhalt.
> Nachgelagert plane ich (für Verallgemeinerung), auch MaxWidth zu
> setzen, dann auf breitesten Wert in allen Zeilen der Spalte.
> Befürchte aber, das dies dann vielleicht zu langsam wird, wenn ich jede
> Row durchkaue ?
Meine tables sind haeufig dynamisch, da sie vom jeweiligen Query
abhaengen, welches ich auf die DB setze.Fixe Zellenbreiten waeren
da deshalb hinderlich; die Performance leidet bei mir manchmal ein
wenig beim Scrollen, wenn die table sehr lang wird. (Das kommt bei
mir aber nur in zwei Faellen vor,das muss ich in Kauf nehmen dann.)
Schlimmer ist es, wenn ich viele columns habe(Query auf sysobjects),
aber das vermeide ich in der Regel.
> > Das hier funktioniert bei mir sehr gut:
> > http://www.chka.de/swing/table/cell-sizes.html
> >
>
> So ähnlich siehts bei mir auch aus.
> Was mich interessiert, wo bindest Du diese Methode ein und wo/wer ruft
> die Methode auf ?
Ich erstelle meine Table in einer extra Klasse, dort rufe ich die
Methode dann auf, das hat bis jetzt immer funktioniert, auch
wenn sich die table dynamisch aendert.
Linda
--
_ " _ When the fantasy bells of the universe ring You can
(_\|/_) fly through the sky on a dragonfly's wing - There is
(/|\) magic within, there is magic without
Kate Bush, The Magician of Lublin
Martin Wronna
[...]
>> So ähnlich siehts bei mir auch aus.
>> Was mich interessiert, wo bindest Du diese Methode ein und wo/wer
>> ruft die Methode auf ?
>
> Ich erstelle meine Table in einer extra Klasse, dort rufe ich die
> Methode dann auf, das hat bis jetzt immer funktioniert, auch
> wenn sich die table dynamisch aendert.
>
Du führst die Spaltenbreitenberechnungen also sozusagen manuell aus,
gezielter Aufruf im Programm.
Ich habs jetzt mal ins tableChanged() der JTable eingebunden.
Funktioniert soweit ganz gut, muss mir nurnoch etwas (besseres)
überlegen wie ich dort an eine FontMetrics des aktuellen Fonts komme.
> Linda
Martin
Christian Kaufhold
Markus Blatt <mbl...@gmx.net> wrote:
[...]
> Ohne jetzt Lindas Beispiel angeschaut zu haben. Ich mache das einem
> TableModelModelListener in der Methode tableModelChanged(TableEvent
> e). ColumnResizer ist wie der Name sagt fuer das Setzen der Groesse
> zustaendig.
> public void tableChanged(TableModelEvent e){
> super.tableChanged(e);
> if(e.getType()==TableModelEvent.UPDATE){
> int col = convertColumnIndexToView(e.getColumn());
> if (col>=0) {
> if(columnResizer != null)
> columnResizer.resizeColumn(col);
> }
> }
> }
1. Es gibt UPDATE-Events, bei denen 'column' -1 ist (das wird ja (im-
plit?) von dem Code schon auch richtig erkannt); nur sollten dann eher
*alle* Spalten neu berechnet werden, als keine(?).
2. Warum nicht auch bei INSERT-Events (die neue Spalte(n) kann genauso
gut breiter sein als die geänderte(n)?
3. Ich als Benutzer fände es sehr nervig, wenn die Spalten ständig
ihre Breite änderten, nur weil ich mal eine Zelle angeklickt habe
(falls das TableModel nicht mehr, daß sich gar nichts geändert hat,
und DefaultTableModel tut es nicht). Automatisch würde ich das nur
machen, wenn tableDataChanged (getToIndex() == Integer.MAX_VALUE)
oder tableStructureChanged (dann ist sowieso alles etwas wage)
vom TableModel ankommen, ansonsten z.B. Doppelklicks auf die Spalte
im Header (o.ä.) dafür verwenden.
Christian
Linda Radecke
Martin Wronna wrote:
> Linda Radecke wrote:
> [...]
> Du führst die Spaltenbreitenberechnungen also sozusagen manuell aus,
> gezielter Aufruf im Programm.
> Ich habs jetzt mal ins tableChanged() der JTable eingebunden.
> Funktioniert soweit ganz gut, muss mir nurnoch etwas (besseres)
> überlegen wie ich dort an eine FontMetrics des aktuellen Fonts komme.
Du gehst ueber die FontMetrics? Ich weiss nicht, ist das so nicht
ineffizienter?: Class FontMetris:
"Note that the implementations of these methods are inefficient,
so they are usually overridden with more efficient toolkit-specific
implementations."
Die Spaltenbreite haengt doch von den Daten selbst ab und von dem
Renderer, der verwendet wird; IMO reicht es doch, das via Renderer
abzufragen.Was ist denn, wenn keine Strings in der Spalte drin-
stehen (Icon, JCheckbox, etc...?)
Martin Wronna
>
>
> Martin Wronna wrote:
>
>> Linda Radecke wrote:
>
>> [...]
>
>> Du führst die Spaltenbreitenberechnungen also sozusagen manuell aus,
>> gezielter Aufruf im Programm.
>> Ich habs jetzt mal ins tableChanged() der JTable eingebunden.
>> Funktioniert soweit ganz gut, muss mir nurnoch etwas (besseres)
>> überlegen wie ich dort an eine FontMetrics des aktuellen Fonts komme.
>
> Du gehst ueber die FontMetrics? Ich weiss nicht, ist das so nicht
> ineffizienter?: Class FontMetris:
>
> "Note that the implementations of these methods are inefficient,
> so they are usually overridden with more efficient toolkit-specific
> implementations."
>
Was für "effizientere" Methoden gibt es denn ?
Stehe bei dem Thema noch völlig am Anfang.
> Die Spaltenbreite haengt doch von den Daten selbst ab und von dem
> Renderer, der verwendet wird; IMO reicht es doch, das via Renderer
> abzufragen.Was ist denn, wenn keine Strings in der Spalte drin-
> stehen (Icon, JCheckbox, etc...?)
Derzeit hab ich "nur" String-Varianten. Versuche mich neben der
normalen Überschrift an einer JText-Variante.
Habs auch am laufen inzwischen.
Kannst Du mir einen Tip geben, wie ich in dem TableCellRenderer für
JTableHeader das korrekt mache ?
Wenn ich darin nichts manipuliere, wird mir der Defaultwert von 75
verwendet. Habe den CellRenderer bisher immer als DefaultCellRenderer
in der JTable gesetzt, direkt je TableColumn hab ich noch nicht
probiert.
Hab mal versucht meine Breite in getPreferredWidth() in dem Renderer zu
setzen, aber danach waren die Spalten fest auf diese Breite fixiert.
Was die FontMetrics angeht, womit bekomme ich denn sonst die aktuelle
Breite des Textes raus, bzw. welche Komponente weiss die von alleine ?
Meine Versuche die Zeichenzahl mal Font-Größe zu rechnen waren nicht
das was ich wollte, da die Fonts je Zeichen verschieden viel Platz
verwenden. Richtig schön siehts bisher nur mit den Metrics aus.
>
>
> Linda
Martin
michael dobrunz
"Martin Wronna" <Tokei...@gmx.net> schrieb
N'abend Martin und ein Hallo an dclj!
> Kannst Du mir einen Tip geben, wie ich in dem TableCellRenderer für
> JTableHeader das korrekt mache ?
<wiederholung>
Schau Dir nochmals Lindas Beispiel an!
http://www.chka.de/swing/table/cell-sizes.html
</wiederholung>
Sie holt sich dort aus der Tabelle das TableColumnModel. An die Table wirst
Du doch irgendwie rankommen. Über columns kommt sie nun an die Komponenten
der Spalten-Köpfe und -Zeilen heran.
Beispielsweise mit:
Component c = h.getTableCellRendererComponent (
table, column.getHeaderValue(), false, false, -1, i);
width = c.getPreferredSize().width;
und der #prefferredSize der Zeilenkomp. (weiter unten im Code) ermittelt sie
die passende Größe der Spalte.
Das funktioniert! Ich habs adaptiert (thx Linda!) und bin zufrieden. Hängt
halt ein wenig von den preferredSize() Implementationen ab.
gruss
micha
Linda Radecke
michael dobrunz wrote:
Den Tip gebe ich gerne, aber es ist Christians Methode :)
Linda ... gerade erst nach Hause gekommen
Linda Radecke
Martin Wronna wrote:
> Linda Radecke wrote:
[...]
>Was für "effizientere" Methoden gibt es denn ?
Fixe Zellenbreiten verwenden...;-)
> Stehe bei dem Thema noch völlig am Anfang.
IMO gibt es diese Funktionalitaet nicht performanceverlustfrei,
wenn jede Zelle abgefragt werden muss, und sich dann evtl.die
Daten auch noch dynamisch aendern.
> Derzeit hab ich "nur" String-Varianten. Versuche mich neben der
> normalen Überschrift an einer JText-Variante.
> Habs auch am laufen inzwischen.
>
> Kannst Du mir einen Tip geben, wie ich in dem TableCellRenderer für
> JTableHeader das korrekt mache ?
> Wenn ich darin nichts manipuliere, wird mir der Defaultwert von 75
> verwendet. Habe den CellRenderer bisher immer als DefaultCellRenderer
> in der JTable gesetzt, direkt je TableColumn hab ich noch nicht
> probiert.
Ich setze den / die Renderer per TableColumn anstatt als
DefaultRenderer auf die JTable (TableColumn, JTableHeader,
TableColumnModel haengen direkt zusammen).
> Hab mal versucht meine Breite in getPreferredWidth() in dem Renderer zu
> setzen, aber danach waren die Spalten fest auf diese Breite fixiert.
>
> Was die FontMetrics angeht, womit bekomme ich denn sonst die aktuelle
> Breite des Textes raus, bzw. welche Komponente weiss die von alleine ?
Der CellRenderer; also, die Zelldarstellung wird ja vom Renderer
bestimmt, und in DefaultTableCellRenderer.java steht ja schon:
setFont(table.getFont());
etc...der ganze Rest....
in:
public Component getTableCellRendererComponent(JTable table,
Object value, boolean isSelected, boolean hasFocus, int row,
int column) {...}
By default ist das dann: UIManager.get("Table.font"):
javax.swing.plaf.FontUIResource
[family=dialog,name=Dialog,style=plain,size=12]
in JTable.java gibt es:
public Font getFont() {....}/public FontMetrics getFontMetrics(Font f) {...}
und auch
public void setFont(Font f) {
AccessibleContext ac = getCurrentAccessibleContext();
if (ac instanceof AccessibleComponent) {
((AccessibleComponent) ac).setFont(f);
} else {
Component c = getCurrentComponent();
if (c != null) {
c.setFont(f);//!
}
}
}
> Meine Versuche die Zeichenzahl mal Font-Größe zu rechnen waren nicht
> das was ich wollte, da die Fonts je Zeichen verschieden viel Platz
> verwenden. Richtig schön siehts bisher nur mit den Metrics aus.
Wie gesagt, ich verwende Christians Methode hierbei.
Martin Wronna
>
>
> Martin Wronna wrote:
>
>> Linda Radecke wrote:
>
> [...]
>
> Ich setze den / die Renderer per TableColumn anstatt als
> DefaultRenderer auf die JTable (TableColumn, JTableHeader,
> TableColumnModel haengen direkt zusammen).
Werd ich mal versuchen.
Wie ist das eigentlich mit Ressourcen, etc ?
IMHO hab ich ja so für jede Spalte einen Renderer rumliegen, während
beim DefaultRenderer nur einer für alle da ist ?
[...]
>
> Der CellRenderer; also, die Zelldarstellung wird ja vom Renderer
> bestimmt, und in DefaultTableCellRenderer.java steht ja schon:
>
> setFont(table.getFont());
>
> etc...der ganze Rest....
>
> in:
>
> public Component getTableCellRendererComponent(JTable table,
> Object value, boolean isSelected, boolean hasFocus, int row,
> int column) {...}
>
>
> By default ist das dann: UIManager.get("Table.font"):
>
> javax.swing.plaf.FontUIResource
> [family=dialog,name=Dialog,style=plain,size=12]
>
Werd ich mir auch nochmal ansehen
>
> in JTable.java gibt es:
>
> public Font getFont() {....}/public FontMetrics getFontMetrics(Font f)
> {...}
Jep, diese beiden Methoden verwend ich zur Zeit.
Für meine 25 Zeilen mit 34 Columns läufts zügig genug.
>
> und auch
>
> public void setFont(Font f) {
> AccessibleContext ac = getCurrentAccessibleContext();
> if (ac instanceof AccessibleComponent) {
> ((AccessibleComponent) ac).setFont(f);
> } else {
> Component c = getCurrentComponent();
> if (c != null) {
> c.setFont(f);//!
> }
> }
> }
Mit diesem Accessible hab ich mich noch nie beschäftigt.
Sehr schlimm ?
[...]
>
> Linda
Grüße, Martin
Martin Wronna
>
>
> michael dobrunz wrote:
>
>>N'abend Martin und ein Hallo an dclj!
>
>> > Kannst Du mir einen Tip geben, wie ich in dem TableCellRenderer für
>> > JTableHeader das korrekt mache ?
>
>> <wiederholung>
>> Schau Dir nochmals Lindas Beispiel an!
>> http://www.chka.de/swing/table/cell-sizes.html
>> </wiederholung>
>
>> Sie holt sich dort aus der Tabelle das TableColumnModel. An die Table
>> wirst Du doch irgendwie rankommen. Über columns kommt sie nun an die
>> Komponenten der Spalten-Köpfe und -Zeilen heran.
>
Ja, komm ich.
Hab inzwischen den entsprechenden Code an 3 verschiedenen Stellen
gehabt, gefiel mir nur nicht.
Drum fragte ich, wo man das am sinnvollsten Implementiert.
Meine Intention ist, dieses Setzen nicht extern in meinem Programm zu
machen, sondern innerhalb einer dafür zuständigen Methoden (im
Renderer, in JTable, in der TableColumn, ...)
>> Beispielsweise mit:
>> Component c = h.getTableCellRendererComponent (
>> table, column.getHeaderValue(), false, false, -1, i);
>> width = c.getPreferredSize().width;
>
>> und der #prefferredSize der Zeilenkomp. (weiter unten im Code)
>> ermittelt sie die passende Größe der Spalte.
>
Diese Stelle werd ich mir nochmal näher anschauen.
Wobei mir der Code im tableChanged() in der JTable schon recht gut
gefällt.
Funktioniert ohne externe Aufrufe und ohne Casten.
>> Das funktioniert! Ich habs adaptiert (thx Linda!) und bin zufrieden.
>> Hängt halt ein wenig von den preferredSize() Implementationen ab.
>
Glaube ich unbesehen.
> Den Tip gebe ich gerne, aber es ist Christians Methode :)
>
>
>
> Linda ... gerade erst nach Hause gekommen
Martin ... bei der Halbzeit des heutigen Abends angekommen und sogar
schon produktiv am Programm was verbessert.
michael dobrunz
"Linda Radecke" <li...@jalice.ch> wrote
[Meine Lobeshymnen]
> Den Tip gebe ich gerne, aber es ist Christians Methode :)
>
Und ich sag noch, beim Ersten gehts schief ;-)
Sorry und thx Christian!
Zu meiner Ehrenrettung. Ich habs irgendwann auf/über jalice.net gefunden.
Sehr inspirierend die Site!
gruss
micha
Linda Radecke
Martin Wronna wrote:
> Werd ich mal versuchen.
> Wie ist das eigentlich mit Ressourcen, etc ?
> IMHO hab ich ja so für jede Spalte einen Renderer rumliegen, während
> beim DefaultRenderer nur einer für alle da ist ?
Sofern kein Renderer spez. auf die TableColumn gesetzt wird,
(die TableColumn hat die ganze Info ueber Renderer, Editor,
Breiten, sizings ... (zusammengefasst im TableColumnModel))
werden *die* DefaultRenderer verwendet,(nach Class type) von
getColumnClass, public void setDefaultRenderer(Class
columnClass, TableCellRenderer renderer) {...}, das kannst
du auch so verwenden. Bspw. kannst du ja auch definieren:
table.setDefaultRenderer(Date.class, new DateRenderer());
table.setDefaultRenderer(Number.class, new FractionRenderer());
table.setDefaultRenderer(String.class, new ColorRenderer());
Dann gibst du halt den jeweiligen Class type mit an und es
wird automatisch richtig gesetzt.
> > By default ist das dann: UIManager.get("Table.font"):
> >
> > javax.swing.plaf.FontUIResource
> > [family=dialog,name=Dialog,style=plain,size=12]
> >
>
> Werd ich mir auch nochmal ansehen
Das ist bspw. in BasicTableUI zu finden.
> Jep, diese beiden Methoden verwend ich zur Zeit.
> Für meine 25 Zeilen mit 34 Columns läufts zügig genug.
Ich meinte eher, dass das im Renderer bereits ja gesetzt ist,
und deshalb bekannt.
> > public void setFont(Font f) {
> > AccessibleContext ac = getCurrentAccessibleContext();
> > if (ac instanceof AccessibleComponent) {
> > ((AccessibleComponent) ac).setFont(f);
> > } else {
> > Component c = getCurrentComponent();
> > if (c != null) {
> > c.setFont(f);//!
> > }
> > }
> > }
>
> Mit diesem Accessible hab ich mich noch nie beschäftigt.
> Sehr schlimm ?
Eigentlich nicht, es ist ein Interface (Assistive Technologies ),
im Tutorial steht ein Abschnitt darueber, ich glaube, ganz am Schluss.
Martin Wronna
>
>
> Martin Wronna wrote:
>
>> Werd ich mal versuchen.
>> Wie ist das eigentlich mit Ressourcen, etc ?
>> IMHO hab ich ja so für jede Spalte einen Renderer rumliegen, während
>> beim DefaultRenderer nur einer für alle da ist ?
>
> Sofern kein Renderer spez. auf die TableColumn gesetzt wird,
> (die TableColumn hat die ganze Info ueber Renderer, Editor,
> Breiten, sizings ... (zusammengefasst im TableColumnModel))
> werden *die* DefaultRenderer verwendet,(nach Class type) von
> getColumnClass, public void setDefaultRenderer(Class
> columnClass, TableCellRenderer renderer) {...}, das kannst
> du auch so verwenden. Bspw. kannst du ja auch definieren:
>
> table.setDefaultRenderer(Date.class, new DateRenderer());
> table.setDefaultRenderer(Number.class, new FractionRenderer());
> table.setDefaultRenderer(String.class, new ColorRenderer());
>
> Dann gibst du halt den jeweiligen Class type mit an und es
> wird automatisch richtig gesetzt.
>
Stimmt, das gibts ja auch noch.
>
>
>> > By default ist das dann: UIManager.get("Table.font"):
>> >
>> > javax.swing.plaf.FontUIResource
>> > [family=dialog,name=Dialog,style=plain,size=12]
>> >
>>
>> Werd ich mir auch nochmal ansehen
>
> Das ist bspw. in BasicTableUI zu finden.
>
>> Jep, diese beiden Methoden verwend ich zur Zeit.
>> Für meine 25 Zeilen mit 34 Columns läufts zügig genug.
>
> Ich meinte eher, dass das im Renderer bereits ja gesetzt ist,
> und deshalb bekannt.
>
Ja, allerdings überschreibe ich die, da ich nicht mit den Defaults
arbeiten mag. (Hab meinen Font in den UIManager geladen, jetzt wird der
automatisch geladen.)
>> > public void setFont(Font f) {
>> > AccessibleContext ac = getCurrentAccessibleContext();
>> > if (ac instanceof AccessibleComponent) {
>> > ((AccessibleComponent) ac).setFont(f);
>> > } else {
>> > Component c = getCurrentComponent();
>> > if (c != null) {
>> > c.setFont(f);//!
>> > }
>> > }
>> > }
>>
>> Mit diesem Accessible hab ich mich noch nie beschäftigt.
>> Sehr schlimm ?
>
> Eigentlich nicht, es ist ein Interface (Assistive Technologies ),
> im Tutorial steht ein Abschnitt darueber, ich glaube, ganz am Schluss.
>
>
> Linda
> --
> .-. I hear him, before I go to sleep And focus on the day
> ( ( that's been. I realise he's there, When I turn the
> '-` light off and turn over.
> Kate Bush - The Man With The Child In His Eyes
Thanks, Martin
Linda Radecke
Martin Wronna wrote:
> Linda Radecke wrote:
[...]
> > table.setDefaultRenderer(Date.class, new DateRenderer());
> > table.setDefaultRenderer(Number.class, new FractionRenderer());
> > table.setDefaultRenderer(String.class, new ColorRenderer());
> >
> > Dann gibst du halt den jeweiligen Class type mit an und es
> > wird automatisch richtig gesetzt.
> >
>
> Stimmt, das gibts ja auch noch.
Das ist aus dem Grunde auch recht praktisch, da dynamisch.
> > Ich meinte eher, dass das im Renderer bereits ja gesetzt ist,
> > und deshalb bekannt.
> >
>
> Ja, allerdings überschreibe ich die, da ich nicht mit den Defaults
> arbeiten mag.
Ich auch nicht, ich ueberschreibe den im Renderer, bspw:
if (isSelected) {
setFont(table.getFont().deriveFont(Font.ITALIC)
.deriveFont(14.0f));
....
}
> (Hab meinen Font in den UIManager geladen, jetzt wird der
> automatisch geladen.)
Ja, kannst du machen (der gilt dann fuer alle Tables in der
application), ich loese das aber gleich auf L&F-Ebene dann.
> Thanks, Martin
Likewise:)
Linda ... geht jetzt aber wirklich....:)
Markus Blatt
> Hello!
>
> Markus Blatt <mbl...@gmx.net> wrote:
>
> [...]
>
>
> > Ohne jetzt Lindas Beispiel angeschaut zu haben. Ich mache das einem
> > TableModelModelListener in der Methode tableModelChanged(TableEvent
> > e). ColumnResizer ist wie der Name sagt fuer das Setzen der Groesse
> > zustaendig.
>
> > public void tableChanged(TableModelEvent e){
> > super.tableChanged(e);
>
> > if(e.getType()==TableModelEvent.UPDATE){
> > int col = convertColumnIndexToView(e.getColumn());
>
> > if (col>=0) {
> > if(columnResizer != null)
> > columnResizer.resizeColumn(col);
> > }
> > }
> > }
>
> 1. Es gibt UPDATE-Events, bei denen 'column' -1 ist (das wird ja (im-
> plit?) von dem Code schon auch richtig erkannt); nur sollten dann eher
> *alle* Spalten neu berechnet werden, als keine(?).
Ja, da hast du recht. Kommt zwar in meinem speziellen Fall nicht vor,
aber sollte ich unbedingt einbauen.
>
> 2. Warum nicht auch bei INSERT-Events (die neue Spalte(n) kann genauso
> gut breiter sein als die geänderte(n)?
>
Zu meiner Verteidigung auch dieser Fall kam damals nicht vor, da das
Datenmodell bzgl. der Spalten fix war. Werd ich auch mal einbauen.
> 3. Ich als Benutzer fände es sehr nervig, wenn die Spalten ständig
> ihre Breite änderten, nur weil ich mal eine Zelle angeklickt habe
> (falls das TableModel nicht mehr, daß sich gar nichts geändert hat,
> und DefaultTableModel tut es nicht).
Nun dieser Effekt ist allerdings nicht aufgetreten, da ja dann die
berechnete Breite gleich bleibt. Allerdings wird das ganze natürlich
unheimlich träge und Dank Dir weiß ich jetzt endlich warum!
Danke für den Tipp, bei nächster Gelegenheit wird ein Test auf
Gleichheit eingebaut.
Gruß,
Christian Kaufhold
Markus Blatt <mbl...@gmx.net> wrote:
> use...@chka.de (Christian Kaufhold) writes:
[...]
>> 3. Ich als Benutzer fände es sehr nervig, wenn die Spalten ständig
>> ihre Breite änderten, nur weil ich mal eine Zelle angeklickt habe
>> (falls das TableModel nicht mehr, daß sich gar nichts geändert hat,
>> und DefaultTableModel tut es nicht).
> Nun dieser Effekt ist allerdings nicht aufgetreten, da ja dann die
> berechnete Breite gleich bleibt. Allerdings wird das ganze natürlich
> unheimlich träge und Dank Dir weiß ich jetzt endlich warum!
> Danke für den Tipp, bei nächster Gelegenheit wird ein Test auf
> Gleichheit eingebaut.
Es passiert schon, wenn der Benutzer die Spaltenbreite verändern
kann und es auch hat. Wegen des Skalierens der Breiten werden dann
vermutlich *alle* Spalten ihre Breite auf merkwürdige Weise ändern.
Christian
--
"Well, here we are, Mr Pilgrim, trapped in the amber of this moment.
There is no /why/."
Slaughterhouse-Five