Re: Subclassing NSTableView
Re: Subclassing NSTableView
- Subject: Re: Subclassing NSTableView
- From: Norbert Heger <email@hidden>
- Date: Fri, 26 Oct 2001 02:12:43 +0200
Drew McCormack <email@hidden> wrote:
>
I've been trying to subclass NSTableView so that I can have rows of
>
different heights. I have overrided the layout methods to achieve this
>
(eg rectOfRow), and things seem to go OK. The rows will resize to
>
display all the text in each cell, even when there is less in one column
>
than in another. However, it only works if all rows are exactly the same
>
height. If they are different heights, things go nuts.
>
>
I am starting to think that the implementation of the class may not be
>
flexible enough to do what I want to do. I suspect there may be parts of
>
the base class implementation that do not rely wholly on the layout
>
methods, but also make the assumption that all rows are the same
>
height. Can anyone at Apple tell me if this is right? It would really
>
save me a lot of effort if I knew from the beginning that I was doomed
>
to failure.
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
_____________________________________________
Norbert Heger, Objective Development
http://www.obdev.at/