Re: NSTableView bugs & questions

[Nicola Pero]

Hi Pierre-Yves,

    Pierre-Yves> hi, I have corrected NSTableView so that it behaves
    Pierre-Yves> the way it behaves in OPENSTEP 4.2 : clicking an
    Pierre-Yves> already selected cell does not unselect it, but
    Pierre-Yves> rather leave it selected and unselect all other
    Pierre-Yves> cells.

Thanks - should we fix column selection in the same way ?

    Pierre-Yves> The patch also fixes a bug in
    Pierre-Yves> columnAtPoint. [columnAtPoint: NSMakePoint(0, ?)] 
    Pierre-Yves> would give -1 whereas it should be 0 The only way the
    Pierre-Yves> bug is critical is when you double-click on the left
    Pierre-Yves> edge (you have to be exactly on the edge's line...) 
    Pierre-Yves> of the first column (uncaught exception
    Pierre-Yves> NSRangeException).

Thanks - nice - I applied your patch to CVS.

    Pierre-Yves> I have also located a possible problem in drawRect :

    Pierre-Yves> [self drawRect: [self rectOfRow: _row]] causes the
    Pierre-Yves> redrawing of _row and of the row after _row, which is
    Pierre-Yves> incorrect.

    Pierre-Yves> The problem is in NSTableView.m, (void) drawRect:
    Pierre-Yves> (NSRect)arect L2397 : endingRow = [self rowAtPoint:
    Pierre-Yves> NSMakePoint (0, NSMaxY (aRect))]; A correction would
    Pierre-Yves> be to replace it by endingRow = [self rowAtPoint:
    Pierre-Yves> NSMakePoint (0, NSMaxY (aRect) - 1)]; but this
    Pierre-Yves> assumes integer coordinates.  With float coordinates
    Pierre-Yves> a solution would be endingRow = [self rowAtPoint:
    Pierre-Yves> NSMakePoint (0, NSMaxY (aRect) - 1e-7)]; but the use
    Pierre-Yves> of the 1e-7 value make this code platform dependant ,
    Pierre-Yves> hard to maintain and subject to bugs.

    Pierre-Yves> Does anybody have an idea on how to fix this problem
    Pierre-Yves> easily ?

Argh - that's a good one - I suppose the solution is that we implement
rowsInRect: as a partially standalone method (ie, not relying on
rowAtPoint: for the NSMaxY but rather doing its own search with
different bounday conditions) - and then call that one in drawRect:.

Actually - your remark in a certain sense explains to me why the API
has both rowAtPoint: and rowsInRect: - rowsInRect: is not a simple
wrapper around two rowAtPoint: calls then!