Re: Subclassing NSTableView
Re: Subclassing NSTableView
- Subject: Re: Subclassing NSTableView
- From: Drew McCormack <email@hidden>
- Date: Fri, 26 Oct 2001 14:00:37 +0200
Yep, it's not right.
Forget the particular API and tell me: if one clicks into the middle
area of
the scroller, how would the tableview determine which rows to show?
Simple. It determines what the coordinates of the 'middle' are using the
frame or rectOfColumn: method, or something like that. It then
determines what the visible rectangle will be based on these coordinates
and the size of the scroll view. It passes this rectangle to the method
rowsInRect: to get the range of rows it must draw. It determines the
positions of the cells to be drawn by calling
"frameOfCellAtColumn:row:". Etc.
Of course, you may wonder what the implementation of "rowsInRect:" will
be. In NSTableView, this probably does do a simple calculation under the
assumption of equally sized rows. But, my intention is to override
"rowsInRect:", and other layout methods, so that the assumption of
equally sized rows no longer holds. I will no doubt have to store the
row heights in an array, or something, to make things efficient, but it
should be doable. Tests that I have performed since posting my last
message are promising, and suggest it can be done.
Unless _all_ (ar at least all to the clicked point) row heights are
fetched
(which would be the aforementioned "huge performance problem"), there
is no
way to guess whether, say, first 1000 rows happen to be much higher
than the
rest and so the "middle" happens to be somewhere around row #900, or
whether
the last 1000 happens to be much higher, so the "middle" happens to be
somewhere around #49100.
True, guessing would not be a good idea, but the "rowsInRect:" method
does a pretty good job.
Drew