Hi That is the same approach Swing uses. And it has the same problems - getting events into and out of the cell is tricky and means that the cell component needs various bits of tweaking to cope properly with things like focus gain/release. Also saving/restoring the cell's state can lead to very odd things happening when people forget to save or restore all of the state.
I'm in two minds about this. Personally, I try where-ever possible to avoid using the Swing components that do this (JTable) in favour of putting real components into real containers. However, there are a very few use-cases (editable tables containing very large numbers of rows) that can benefit from this approach. But I'd rather have that as separate class so that only the people who really need that kind of thing have to pay the price for dealing with the hidden complexities. -- Noel Dirk Möbius wrote: > Greg Brown <[email protected]> wrote: > > No, TableViews can't contain other components. > > @Greg: allow me to add a small remark here since this question will > come up again a couple of times: > > See how the JavaFX team used cell renderers > <http://fxexperience.com/2010/04/new-to-javafx-1-3-cells/> to > accomplish this. In short, a ListView/TreeView/TableView is assigned > with a CellFactory that creates a Cell which contains an arbitrary > component. The Cell is reused (rubberstamp approach) to render the > visible list/tree/table cells, but the outer > ListView/TreeView/TableView redirects all mouse and keyboard events to > the Cell, so that the component inside the Cell gets full behavior. > Using the bind mechanism, the programmer defines which properties of > the component get updated whenever a new cell is displayed through > scrolling. The JavaFX team managed to implement this both memory and > time efficient. > > Something you might consider for 2.0. :-) > > Dirk. >
