[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSTableView bugs & questions
From: |
Nicola Pero |
Subject: |
Re: NSTableView bugs & questions |
Date: |
Mon, 29 Jan 2001 20:41:49 +0000 (GMT) |
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!