Re: Subclassing NSTableView
Re: Subclassing NSTableView
- Subject: Re: Subclassing NSTableView
- From: Drew McCormack <email@hidden>
- Date: Fri, 26 Oct 2001 09:43:39 +0200
As far as I can tell, this can't work by subclassing NSTableView.
For performance and efficiency reasons NSTableView is designed to load
the
data displayed in the visible rows lazily (on demand). Therefore
NSTableView
must be able to determine the range of rows that have do be displayed
at a
given scroller position. If the rows do not have the same heights it
would
be necessary to know the heights of ALL rows in advance, in order to
calculate the visible range of rows.
Just imagine a table of 50.000 rows, the vertical scroller somewhere in
the
middle. Given the current design (assuming that all rows do have the
same
height), this is no problem at all. With different row heights this
would be
a huge performance problem.
Best Regards, Norbert
Thanks for your response Norbert. Actually, I'm not sure if what you
suggest is actually true. There are many layout methods in NSTableView,
and I think some of them would be used to determine the visible rows in
a scrollview. Here they are:
- rectOfColumn:
- rectOfRow:
- columnsInRect:
- rowsInRect:
- columnAtPoint:
- rowAtPoint:
- frameOfCellAtColumn:row:
- setAutoresizesAllColumnsToFit:
- autoresizesAllColumnsToFit
- sizeLastColumnToFit
- noteNumberOfRowsChanged
- tile
I suspect that the rowsInRect: method would be used to determine which
rows to draw. Does anyone else know if this is right?
Drew