gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Table view bug?


From: Fred Kiefer
Subject: Re: Table view bug?
Date: Sun, 19 Jan 2014 23:35:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 17.01.2014 20:14, David Chisnall wrote:
> I'm seeing some odd behaviour with NSTableView.  My table column is
> editable and my delegate's -tableView:objectValueForTableColumn:row:
> returns a string.  I can then click on the string and edit it and
> everything works as expected.  If, however, the delegate returns
> either the empty string (@"") or nil, then it usually doesn't let me
> edit it.  When I double click, the field editor appears, but I can't
> type into it.  Sometimes it appears and I can type into it, but it
> loses the first character (or, sometimes, the first character that I
> type with shift pressed).

I am able to reproduce this behaviour and the problem with the empty
string seems only to happen when it is the first cell in the table view
that gets edited. After editing another cell it seems to work fine.
And sometimes it works when you click on the empty cell and move the
focus to a different window and then back again. It is almost as if the
text view used as the cell editor does not accept key events.
But the problem seems to be deeper. In NSTextView
replaceCharactersInRange:withString: we end up in the case
([_textStorage length] == 0) and there the created attributed string
seems to be nil. I am really confused here, as this can never be.

> I've now worked around it by returning @" " when I want an empty,
> editable, field, but I'd appreciate it if someone who understands the
> NSTableView / NSCell code could take a look.
> 
> On an unrelated note, it's increasingly difficult to share nib/xib
> files with OS X, since we don't support the new format, and XCode
> defaults to using (the quite confusing) layout constraints mechanism
> instead of the comprehensible one, and so even with the new format we
> can't load xibs that use NSLayoutConstraint, which apparently uses
> this (LGPL) constraint solver:
> http://www.cs.washington.edu/research/constraints/cassowary/

That is quite interesting. I have been thinking about writing a reader
for the new format, similar to the way we support Renaissance, but as
Greg wrote he is working on this already I rather wait for him to finish.

Fred



reply via email to

[Prev in Thread] Current Thread [Next in Thread]