NSTableView editing problem [Was: Next stable release?]

[Fred Kiefer]

Matt Rice wrote:
> On Fri, Jun 6, 2008 at 12:32 PM, Fred Kiefer <address@hidden> wrote:
> > Matt Rice wrote:
> > > I did notice an NSTableView bug though, and its reproducable afaict
> > > with any editable tableview if you edit a field after editing its row
> > > never set as needing display, you have to click a row to get things to
> > > redraw.
> > Matt,
> >
> > I did not quite understand this description (Did you mean "cell" where you
> > wrote "row"?), but if you have a fix for this, it surely is welcome.
>
>
> no, i meant if you double click a cell, then type something and hit
> enter or tab keys
>
> after that the whole row is not redrawn (except for the field editor)
> and sometimes the whole tableview is blanked out the behaviour changes
> on different apps.
>
> I think we can kind of rule out NSTableView I tested the last known
> version that I know worked
>
> (r24478 of -make,base,gui,back) and that worked still...
>
> then i tested the svn head versions of make,base,gui,back
> with the r24478 version of NSTableView and that produced the same results.

Thank you Matt that is a very interesting finding. I have spend quite 
some time now to test this problme, but failed to get down to the bottom 
of it. It would be best if you put it into our bug system, together with 
the test application you send me off line and all the findings you have 
up to now.

I only tested with the current version of the NSTableView code, but I 
agree, what I see there looks right. But then where does the wrong 
result come from?

> NSTableView drawing right now is fairly susceptible to attacks by
> things setting it as needing display besides itself.
>
> see NSTableView.m (-drawRect:)
>
> it blanks out the background of the entire rect
> with
>
> [self drawBackgroundInClipRect:aRect];
> and highlights the selection then draws the grid.
>
> but if you look at -drawRow:clipRect:
>
> if (i != _editedColumn || rowIndex != _editedRow)
>        {
>           does drawing stuff..
>        }
>
> this code is fairly old and uncommented what i recall it doing is
> not drawing the edited row or column because it doesn't want to draw
> over top of the field editor.

This mechanism seems to work well, form the output I get, the right 
cells get redrawn after hitting return. It just doesn't get visible.
Are we missing a flush somewhere?

> anyhow from the same version of NSTableView both working and not
> working it seems as though NSTableView doesn't set the edited row rect
> as needing display but either the field editor, or NSTextFieldCell or
> something else maybe is setting it as needing display that is my
> guess... anyways

When finishing editing, the NSTableView sets the edited cell as needing 
display. Then the selection changes and both the old and the new 
selected rows get marked for needing display. All of this is correct.

I even tried to hack into the NSView drawing mechanism and now get a 
report whenever drawRect: gets called and this also seems to be totally 
correct. Here is what I get after finishing editing cell 5/0 of your 
test application:

2008-06-08 18:47:05.419 foo[7021] Drawing view <NSTableView: 0x83a0de0> 
rect {x = 0; y = 80; width = 481; height = 32}
2008-06-08 18:47:05.420 foo[7021] Draw cell at row 5 col 0 in rect {x = 
4.5; y = 81; width = 91; height = 14}
2008-06-08 18:47:05.420 foo[7021] Draw cell at row 5 col 1 in rect {x = 
104.5; y = 81; width = 372; height = 14}
2008-06-08 18:47:05.420 foo[7021] Draw cell at row 6 col 1 in rect {x = 
104.5; y = 97; width = 372; height = 14}
2008-06-08 18:47:05.420 foo[7021] Draw cell at row 7 col 0 in rect {x = 
4.5; y = 113; width = 91; height = 14}
2008-06-08 18:47:05.420 foo[7021] Draw cell at row 7 col 1 in rect {x = 
104.5; y = 113; width = 372; height = 14}
2008-06-08 18:47:05.420 foo[7021] Drawing view <NSClipView: 0x8285be8> 
rect {x = 0; y = 0; width = 91; height = 14}
2008-06-08 18:47:05.420 foo[7021] Drawing view <NSTextView: 0x82ebe78> 
rect {x = 0; y = 0; width = 91; height = 14}


OK, there is no reason to redraw row 7, but this wont do any harm. But 
all the rest is completely as expected. I will now look into the window 
flushing, if this is also correct, I am totally clueless.

Fred