André Dietisheim schrieb: > Hi Tom > > CompositeTable of course has a notion of row. The difference is that the > rows are adressed as composite aka controls-container. All operations > compositeTable executes on rows are based on this 'paradigm' > (focus-traversal, cell-layout, etc.). I am not 100% aware of the latest > 3.3 jface implementation but I assume that the main problem when using > items is that rows are reused in compositeTable (rows scrolled out are > refreshed with different model-content.
That's certainly a problem. The only thing I can say is that there's only one place in JFace where we cache rows is when you turn call setUseHashLookup(true). I think it's worth trying if I look at the long list Peter gave in his mail. > Furthermore compositeTable does not have the notion of labelProviders. A > row is a container of controls, cells are controls. There's no > (out-of-the-box) difference in displaying and editing data (and no > label-provider in the strict sense). It's up to the cell-control to decide This not a problem any more you are completely free in the new JFace implementation when it comes to presentation. The viewer calls CellLabelProvider#updateCell(ViewerCell) whenever it wants to display information in a cell. What you are doing in there is up to you. > how to display cell values. Dave's concept is to let the user programmer > implement a cell-editor & label-provider scheme if he needs it. > Is this behavior compatible to the current jface implementation? I admit that the editing thing is a problem but I haven't thought really about it. > I am still here to do some work on this great widget though my work-time > is limited now ;-( > Furthermore the final decisions are up to Dave... Tom _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
