Yup, Ken hits the target dead on; it sounds like it is simply due to
the cell not having the binding. But please do log a bug requesting
this for bindings. Also, thank you for logging the other bug -- I
routed it to IB.
corbin
On Aug 20, 2008, at 1:35 AM, Ken Ferry wrote:
On Tue, Aug 19, 2008 at 8:51 PM, Dave Dribin <[EMAIL PROTECTED]>
wrote:
On Aug 19, 2008, at 5:47 PM, Dave Dribin wrote:
Again, what's strange is if I change my cell's superclass to be
NSTextFieldCell, this bind: call does not give an error and it all
works. I
also tried subclassing NSActionCell, and that works, too. Is my
cell not
implementing some method that bindings expects to be there?
Something that
is implemented in NSActionCell?
Well, scratch that. I just tried using NSActionCell again, and I
still get
the binder warning. I must have messed up my testing the last time
around.
Looks like it needs to be an NSTextFieldCell.
FYI, you should avoid using direct subclasses of NSCell in controls on
Leopard and previous.
Corbin is probably looking at SnowLeopard code, where NSActionCell is
a simple subclass. On Leopard and previous lots of logic that you
might expect to be in NSCell is actually in NSActionCell. Most of
this stems from NSCell not having storage for the controlView - the
controlView method will always return nil on NSCell.
It's somewhat unfortunate, but there are many cases where messages
need to flow from a cell up to a view. If your cell isn't an action
cell, that message flow won't work. It's usually fine as long as your
cell is purely stamped out drawing. If your cell has more complicated
interactions with the user, like use of a field editor or rollovers or
what have you, you're liable to see problems with non-action cells.
[column bind:@"value"
toObject:controller
withKeyPath:@"arrangedObjects.whatever"
options:nil];
I suspect the problem here is that NSCell and NSActionCell don't have
a value binding! Check the Cocoa bindings reference.
Object <NSTableColumn: 0x256740> is not usable with binder of class
NSTextValueBinder
I'm not sure about this, but it might be something along these lines:
Like with target-action and delegate connections, IB doesn't actually
live-instantiate bindings and just archive the whole mess of objects.
Rather the bindings to be hooked up are saved on the side in the nib,
and hooked up at runtime after init'ing objects.
The information about how the bindings need to be hooked up may be
determined at design time in IB. If IB thinks you have a text cell,
you might get a binding set up in a way appropriate for a text cell.
In any case, this 'binder' thing should have a bug too, if you please.
If you want to go the bindings route, you could implement a value
binding on your cell subclass by overriding -bind:toObject:
withKeyPath:options: and then bind at runtime. That'd probably do the
trick.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
