[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cell editing in TableView
From: |
Matt Rice |
Subject: |
Re: Cell editing in TableView |
Date: |
Thu, 23 Nov 2006 04:49:50 -0800 (PST) |
--- Matt Rice <ratmice@yahoo.com> wrote:
>
> --- Guenther Noack <guenther@unix-ag.uni-kl.de>
> wrote:
>
> > Hi!
> >
> > I recently wrote a custom NSCell subclass to
> display
> > and edit
> > iTunes-like star ratings in a NSTableView. Apart
> > from the obvious
> > constructor methods, I overrode a -draw... method,
> > the
> > -trackMouse:at:... method and the
> -stopTracking:...
> > method. The
> > -trackMouse:at:... method just assigns the
> cellFrame
> > to a field in the
> > cell and then calls itself on the superclass, so
> > that -stopTracking:...
> > knows the current cell frame when it's clicked and
> > can decide which star
> > has been clicked.
> >
> > My problem is: When putting this NSCell in a table
> > row, it works as
> > expected, but when I double click on it, there's
> > suddenly a text field
> > in top of it that allows me to change the value as
> > text. I assume this
> > is caused by the NSCell passing along its mouse
> > events to the table row
> > or the table. Do you know how to stop this text
> > field from appearing?
>
> theres 2 issues currently with using custom cells
> and double click.
>
> when you fix this one, you'll discover there is
> another, but first this issue.
>
> theres many ways to fix this
>
> [cell setEditable:NO];
> this will cause track mouse to work, and as long as
> the table column is editable the objectValue will
> still be
> updated if the object value changes.
> (this is an undefined behaviour, its currently the
> only way to work around both issues from inside the
> cell class)
>
> respond NO for -tableView:shouldEditTableColumn:row:
> fixes both, well defined
>
> set the cell type to something non-NSTextCellType
> has the same effect as
> overridding -editWithFrame:... to do nothing
> (works around only the issue you describe).
>
> the next issue you will discover is that, after
> double
> clicking, and -editWithFrame: is called NSTableView
> refuses to draw the editable cell, because it will
> potentially draw on top of the field editor.
>
> heres a patch i proposed not so long ago for the
> second issue.
>
>
http://lists.gnu.org/archive/html/gnustep-dev/2006-11/msg00041.html
>
> it doesn't match the cocoa behaviour,
>
> (drawing an NSTextFieldCell on top of an active
> field
> editor does draw over top of the field editor).
>
> maybe they're using class introspection to not draw
> NSTextFieldCells, i have no idea
>
Setting the table column to not editable should work
now, i removed a check for editablity which was in the
mouse tracking code, where editablity only involves
text input via keyboard or whatever.
I'm actually now leaning twords not applying my patch
to gui, and just not fixing it, inside of gui and
instead relying on developers to set their cell
editablity or column editablity appropriately,
because the editing code is in NSCell not in
NSTextFieldCell changing the existing NSCell
subclasses to handle this a custom cell class such as
your own wouldn't work,
and limiting editColumn:... in NSTableView to
NSTextFieldCell classes seems entirely wrong but sure
would fix it.
i'll try to write some better docs on NSTableView with
custom cell classes and their potential issues
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com