NSTableColumn not usable with binder of class NSTextValueBinder?
-
Hello,
When I hit the "Delete" key in one of my table views, I get the
following error logged to the console:
Object <NSTableColumn: 0x256740> is not usable with binder of class
NSTextValueBinder
I also don't get the typical "Beep" that happens when a key press goes
off the end of the responder chain. What does this error mean? Have I
messed up my bindings somehow? The bindings seem to be working just
fine, though.
I'm using Xcode 3.1 and the 10.5 SDK.
Thanks,
-Dave -
On Aug 19, 2008, at 3:27 PM, Dave Dribin wrote:
> Hello,
>
> When I hit the "Delete" key in one of my table views, I get the
> following error logged to the console:
>
> Object <NSTableColumn: 0x256740> is not usable with binder of class
> NSTextValueBinder
Further information: I have one column with a custom NSCell subclass.
However, in IB, this column's cell is an NSTextFieldCell, and I
replace the cell in awakeFromNib. I don't see a way to set the
column's cell to a direct NSCell subclass in IB.
As a test, I changed my custom cell to subclass NSTextFieldCell
instead of NSCell and the console error goes away and the "Delete" key
actually deletes the row. But this seems wrong as it's not displaying
any text, though.
-Dave -
On Aug 19, 2008, at 2:20 PM, Dave Dribin wrote:
> On Aug 19, 2008, at 3:27 PM, Dave Dribin wrote:
>> Hello,
>>
>> When I hit the "Delete" key in one of my table views, I get the
>> following error logged to the console:
>>
>> Object <NSTableColumn: 0x256740> is not usable with binder of class
>> NSTextValueBinder
>
> Further information: I have one column with a custom NSCell
> subclass. However, in IB, this column's cell is an NSTextFieldCell,
> and I replace the cell in awakeFromNib. I don't see a way to set
> the column's cell to a direct NSCell subclass in IB.
You can in IB3; just double click on the cell...then set the class.
Otherwise, you have to manually set up your binding in code after you
set the [tableColumn dataCell]. The binding is specific to the cell
type. If you need a code example, I can dig one up.
corbin -
On Aug 19, 2008, at 5:19 PM, Corbin Dunn wrote:
> You can in IB3; just double click on the cell...then set the class.
It's not letting me set it to my custom cell. It just beeps (IB
version 3.1, build 670). I think this is because the column is setup
a text field cell, and it will only let me set the class to an
NSTextFieldCell subclass. There's no plain NSCell in the Library from
what I can find.
> Otherwise, you have to manually set up your binding in code after
> you set the [tableColumn dataCell]. The binding is specific to the
> cell type. If you need a code example, I can dig one up.
Just tried that, too, and now I get the following error in the console
(with -NSBindingDebugLogLevel 1):
Cocoa Bindings: Error accessing bound property value of object
<NSTableColumn: 0x256ca0>: [<NSTableColumn 0x256ca0>
valueForUndefinedKey:]: this class is not key value coding-compliant
for the key value.
Here's my code, which looks very similar to the ManualBindings sample
code:
[column bind:@"value"
toObject:controller
withKeyPath:@"arrangedObjects.whatever"
options:nil];
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?
-Dave -
On Aug 19, 2008, at 3:47 PM, Dave Dribin wrote:
> On Aug 19, 2008, at 5:19 PM, Corbin Dunn wrote:
>> You can in IB3; just double click on the cell...then set the class.
>
> It's not letting me set it to my custom cell. It just beeps (IB
> version 3.1, build 670). I think this is because the column is
> setup a text field cell, and it will only let me set the class to an
> NSTextFieldCell subclass. There's no plain NSCell in the Library
> from what I can find.
Yeah, your correct; please log a bug on this and we will try to fix
it. A "hacky" workaround is to temporarily subclass NSTextFieldCell,
then set it in iB, then undo the change. But, the binder will probably
be wrong...so that doesn't help you too much.
>
>
>> Otherwise, you have to manually set up your binding in code after
>> you set the [tableColumn dataCell]. The binding is specific to the
>> cell type. If you need a code example, I can dig one up.
>
> Just tried that, too, and now I get the following error in the
> console (with -NSBindingDebugLogLevel 1):
>
> Cocoa Bindings: Error accessing bound property value of object
> <NSTableColumn: 0x256ca0>: [<NSTableColumn 0x256ca0>
> valueForUndefinedKey:]: this class is not key value coding-compliant
> for the key value.
>
> Here's my code, which looks very similar to the ManualBindings
> sample code:
>
> [column bind:@"value"
> toObject:controller
> withKeyPath:@"arrangedObjects.whatever"
> options:nil];
>
> 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?
I'm not aware of any specific code for it; NSActionCell is a very
simple subclass. Maybe the bindings code looks for that class
specifically, in order to know when values change.
thanks,
corbin -
On Aug 19, 2008, at 7:03 PM, Corbin Dunn wrote:
>> It's not letting me set it to my custom cell. It just beeps (IB
>> version 3.1, build 670). I think this is because the column is
>> setup a text field cell, and it will only let me set the class to
>> an NSTextFieldCell subclass. There's no plain NSCell in the
>> Library from what I can find.
>
> Yeah, your correct; please log a bug on this and we will try to fix
> it. A "hacky" workaround is to temporarily subclass NSTextFieldCell,
> then set it in iB, then undo the change. But, the binder will
> probably be wrong...so that doesn't help you too much.
FYI, I filed this as rdar://problem/6161481.
-Dave -
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.
-Dave -
On Tue, Aug 19, 2008 at 8:51 PM, Dave Dribin <dave-ml...> 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.
-Ken
Cocoa Frameworks -
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 <dave-ml...>
> 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.
-
On Aug 19, 2008, at 10:51 PM, Dave Dribin 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.
Well, it seems I've been confusing myself with all my testing. It
turns out that NSActionCell *does* work. But, I also needed to setup
the bindings manually in code in awakeFromNib.
So, the current solution is to subclass NSActionCell instead of NSCell
*and* setup bindings in code instead of IB. Neither on its own works.
-Dave -
On Aug 20, 2008, at 3:35 AM, Ken Ferry wrote:
> FYI, you should avoid using direct subclasses of NSCell in controls on
> Leopard and previous.
Well, that settles that, then. ;)
> 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.
This cell is just drawing, but given the bindings issue and the advice
above, it looks like staying away from NSCell is a good idea, ATM.
> I suspect the problem here is that NSCell and NSActionCell don't have
> a value binding! Check the Cocoa bindings reference.
Well, the Cocoa bindings reference does not have an entry for either
NSCell or NSActionCell. For the next best thing, I printed out the
return value of -exposedBindings for both. For NSCell, we've got
these bindings:
Exposed bindings: (
editable,
enabled,
font,
fontBold,
fontFamilyName,
fontItalic,
fontName,
fontSize
)
And for NSActionCell, we've got these:
Exposed bindings: (
editable,
enabled,
font,
fontBold,
fontFamilyName,
fontItalic,
fontName,
fontSize,
value
)
Indeed, NSActionCell has a "value" binding while NSCell does not.
> 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.
The NSTextValueBinder error message is a bug? Or the fact that NSCell
does not have a "value" binding? Or both? ;)
> 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.
I tried this, and it does not work. In fact -
bind:toObject:withKeyPath:options: never gets called in my NSCell
subclass. I even called [self exposeBinding:@"value"] in +initialize,
and bind:toObject:... still does not get called. Is this a different
bug? It seems like I should be able to add bindings to an NSCell
subclass in this way.
In any case, I'm back to subclassing NSActionCell as the way to get
this working.
-Dave -
On Wed, Aug 20, 2008 at 10:33 PM, Dave Dribin <dave-ml...> wrote:
> And for NSActionCell, we've got these:
>
> Exposed bindings: (
> editable,
> enabled,
> font,
> fontBold,
> fontFamilyName,
> fontItalic,
> fontName,
> fontSize,
> value
> )
>
> Indeed, NSActionCell has a "value" binding while NSCell does not.
Oh, huh. I thought I did that test too.
>> 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.
>
> The NSTextValueBinder error message is a bug? Or the fact that NSCell does
> not have a "value" binding? Or both? ;)
Maybe both.. I meant the first.
Bindings are a little bit odd, in that they overload a name like
'value' to do rather different things. NSTextView has a value
binding, for example, that has no relation to the value binding on
NSTextFieldCell. You could say that both are 'values', but it's
unlikely that much code would be able to deal generically with both.
There's no property corresponding to 'value', it's defined specially
for each object that has the binding. I personally don't know why it
couldn't just correspond to objectValue for NSCell, but I might not
know the details.
>> 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.
>
> I tried this, and it does not work. In fact
> -bind:toObject:withKeyPath:options: never gets called in my NSCell subclass.
> I even called [self exposeBinding:@"value"] in +initialize, and
> bind:toObject:... still does not get called. Is this a different bug? It
> seems like I should be able to add bindings to an NSCell subclass in this
> way.
I meant that you should call bind:toObject:withKeyPath:options:
yourself rather than relying on IB to do it.
Like I said (or meant to say), I suspect the problem is that IB is
_not_ going through bind:toObject:withKeyPath:options: at nib loading
time, but rather setting up some objects that it determined at design
time in IB.
> In any case, I'm back to subclassing NSActionCell as the way to get this
> working.
Sounds like a plan.
-Ken -
On Aug 21, 2008, at 12:45 AM, Ken Ferry wrote:
>> The NSTextValueBinder error message is a bug? Or the fact that
>> NSCell does
>> not have a "value" binding? Or both? ;)
>
> Maybe both.. I meant the first.
Well, more information. I found the code that was directly
responsible for causing the error. It was in some code that was
posing as NSTableView (no, I didn't write it, and I now plan to
replace it :), so it was well hidden and I didn't even know it existed.
It turns out calling [column infoForBinding:@"value"] can cause that
error message and an exception to be thrown. In this case, I was
binding to a column with a text field cell setup in IB, but then
changing the cell in code in awakeFromNib. Calling infoForBinding: on
this column, after changing the cell, gives that error. From what you
said about IB doing text cell specific binding stuff, this isn't
overly surprising. So maybe this is not quite a bug after all, as
it's more of a "hey, this isn't a text cell, you dummy". Though maybe
the error message could be a bit more helpful?
> I meant that you should call bind:toObject:withKeyPath:options:
> yourself rather than relying on IB to do it.
But that's exactly what I am doing. I've got no bindings on the
column in IB, and in awakeFromNib, I'm calling bind:toObject:... on
the table column. I don't call it on the cell. I'm assuming the
table column passes the binding along to the cell somehow. It seems
that "value" can be bound to a NSTableColumn only for certain cells
(NSActionCell and subclasses)? Does the table column special case
NSActionCell?
Here's a stack trace when binding to "value" of a cell that is a
direct NSCell subclass. "self" at #3 is an NSTableColumn:
2008-08-22 00:16:08.540 CellBinder[69717:10b] [<NSTableColumn
0x101ed80> valueForUndefinedKey:]: this class is not key value coding-
compliant for the key value.
2008-08-22 00:16:08.540 CellBinder[69717:10b] *** Terminating app due
to uncaught exception 'NSUnknownKeyException', reason:
'[<NSTableColumn 0x101ed80> valueForUndefinedKey:]: this class is not
key value coding-compliant for the key value.'
#1 0x901690fb in objc_exception_throw ()
#2 0x962dac71 in -[NSException raise] ()
#3 0x94d03ea3 in -[NSObject(NSKeyValueCoding) valueForUndefinedKey:] ()
#4 0x94bfb69b in _NSGetUsingKeyValueGetter ()
#5 0x94bfb1aa in -[NSObject(NSKeyValueCoding) valueForKey:] ()
#6 0x94c28d2a in -[NSObject(NSKeyValueCoding) valueForKeyPath:] ()
#7 0x90af02da in -[NSObjectParameterBinder
_updateObject:observedController:observedKeyPath:context:] ()
#8 0x90af0048 in -[NSObjectParameterBinder
_observeValueForKeyPath:ofObject:context:] ()
#9 0x90aefe77 in -[NSBinder _performConnectionEstablishedRefresh] ()
#10 0x90ae80e8 in -[NSObject(NSKeyValueBindingCreation)
bind:toObject:withKeyPath:options:] ()
#11 0x000022e5 in -[CellBinder_AppDelegate awakeFromNib]
(self=0x1035680, _cmd=0x90232928) at /tmp/CellBinder/
CellBinder_AppDelegate.m:20
#12 0x962e9955 in -[NSSet makeObjectsPerformSelector:] ()
#13 0x908fbbe6 in -[NSIBObjectData
nibInstantiateWithOwner:topLevelObjects:] ()
#14 0x908f1e12 in loadNib ()
#15 0x908f1774 in +[NSBundle(NSNibLoading)
_loadNibFile:nameTable:withZone:ownerBundle:] ()
#16 0x908f13b7 in +[NSBundle(NSNibLoading)
loadNibFile:externalNameTable:withZone:] ()
#17 0x908f12f5 in +[NSBundle(NSNibLoading) loadNibNamed:owner:] ()
#18 0x908f0fa4 in NSApplicationMain ()
#19 0x000021f0 in main (argc=1, argv=0xbffff7c8) at /tmp/CellBinder/
main.m:13
-Dave -
On Aug 21, 2008, at 12:45 AM, Ken Ferry wrote:
>> The NSTextValueBinder error message is a bug? Or the fact that
>> NSCell does
>> not have a "value" binding? Or both? ;)
>
> Maybe both.. I meant the first.
I just filed three bugs:
rdar://problem/6178538
infoForBinding:@"value" on an NSTableColumn logs error and throws
exception
rdar://problem/6178546
Binding a table column to NSCell subclass results in a KVC error and
exception
rdar://problem/6178564
NSCell is missing the "value" binding
-Dave -
Ron Lue-Sang Re: NSTableColumn not usable with binder of class NSTextValueBinder? Aug 27 2008, 08:34Woah.
If you really want to use a custom cell, you're gonna want a custom
column as well. The bindings for the tableColumn come from the
tableColumn's dataCell's available bindings. Yea, as you've found,
NSActionCell has a value binding, not plain old NSCell.
But of course, nothing's as simple as it seems to be. It's not like
the tableColumn asks for its dataCell's exposedBindings and then just
re-expose those bindings. It's just not that simple.
Don't ask. Feel free to file a bug tho.
Developers, however, are free to do this in their NSTableColumn
subclasses. So you're custom cell implements and exports an extra
binding. The trick is - how do you go from your cell's binding name to
a setter? You need to implement NSTableColumn's dataCellForRow: to
return a fully set up dataCell - with all the values specified by the
binding "put" into the datacell. Doing this is easy enough if you use
the same name for the cell's binding as you would for the setter.
The reason you're seeing the exception is that you've switched out
the cell out from under the tablecolumn before the binding is set up.
When the tableColumn is issued the bind:… command, it falls back to
the plain old KVB implementation which assumes NSTableColumn
implements setValue: (KVC compliant for "value" key).
Does any of this make sense?
Possibly, you've already solved this some other way, but hopefully
I've cleared up a couple of things.
On Aug 20, 2008, at 10:33 PM, Dave Dribin wrote:
> On Aug 20, 2008, at 3:35 AM, Ken Ferry wrote:
>> FYI, you should avoid using direct subclasses of NSCell in controls
>> on
>> Leopard and previous.
>
> Well, that settles that, then. ;)
>
>> 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.
>
> This cell is just drawing, but given the bindings issue and the
> advice above, it looks like staying away from NSCell is a good idea,
> ATM.
>
>> I suspect the problem here is that NSCell and NSActionCell don't have
>> a value binding! Check the Cocoa bindings reference.
>
> Well, the Cocoa bindings reference does not have an entry for either
> NSCell or NSActionCell. For the next best thing, I printed out the
> return value of -exposedBindings for both. For NSCell, we've got
> these bindings:
>
> Exposed bindings: (
> editable,
> enabled,
> font,
> fontBold,
> fontFamilyName,
> fontItalic,
> fontName,
> fontSize
> )
>
> And for NSActionCell, we've got these:
>
> Exposed bindings: (
> editable,
> enabled,
> font,
> fontBold,
> fontFamilyName,
> fontItalic,
> fontName,
> fontSize,
> value
> )
>
> Indeed, NSActionCell has a "value" binding while NSCell does not.
>
>> 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.
>
> The NSTextValueBinder error message is a bug? Or the fact that
> NSCell does not have a "value" binding? Or both? ;)
>
>> 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.
>
> I tried this, and it does not work. In fact -
> bind:toObject:withKeyPath:options: never gets called in my NSCell
> subclass. I even called [self exposeBinding:@"value"] in
> +initialize, and bind:toObject:... still does not get called. Is
> this a different bug? It seems like I should be able to add
> bindings to an NSCell subclass in this way.
>
> In any case, I'm back to subclassing NSActionCell as the way to get
> this working.
>
> -Dave
--------------------------
RONZILLA -
On Aug 27, 2008, at 1:34 AM, Ron Lue-Sang wrote:
> Woah.
> If you really want to use a custom cell, you're gonna want a custom
> column as well. The bindings for the tableColumn come from the
> tableColumn's dataCell's available bindings. Yea, as you've found,
> NSActionCell has a value binding, not plain old NSCell.
>
> [.. snip ..]
>
> Does any of this make sense?
> Possibly, you've already solved this some other way, but hopefully
> I've cleared up a couple of things.
Yeah, this all mostly makes sense. I'm content just subclassing
NSActionCell for this case, though.
FWIW, what I am trying to do is create a circular, nondeterminate (pie
chart style) progress indicator cell and use it in a table column. So
it's just doing some drawing based on objectValue (I'm using nil to
mean hide the progress). Of course, I want to use bindings to hook
this up to my model, too. Subclassing NSCell and binding the column's
"value" seemed like the best approach.
-Dave
