I had been using the traditional Java TableCellRenderer
approach for providing the renderers in a scala.swing.Table
where I declare my renderers on the table's TableColumnModel
. The code for this looked like:
val myTable = new Table {
lazy val tcm = initColumnModel
peer.setColumnModel(tcm)
override
protected def rendererComponent(sel: Boolean, foc: Boolean, row: Int, col: Int) = {
//GET THE VALUE FROM THE TableModel
val value = model.getValueAt(
peer.convertRowIndexToModel(row),
peer.convertColumnIndexToModel(col))
//GET THE RENDERER FROM THE ColumnModel
val renderer = tcm.getColumn(col).getCellRenderer
//WRAP IN A COMPONENT
Component.wrap(renderer.getTableCellRendererComponent(
peer,
value,
sel,
foc,
row,
col).asInstanceOf[JComponent])
}
}
Unfortunately this appears to have a memory leak - presumably because I am creating a new Component instance for every cell in the table (for ~30k rows). Certainly when I replace my scala table with a JTable
(using exactly the same column and data models) my memory leak goes away.
My question is therefore, what sort of code do people use when overriding the rendererComponent
method assuming one has ones own cell renderers?
peer.convertColumnIndexToModel(col)
instead ofpeer.convertColumnIndexToModel(row)
– Nagel