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 _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
