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
  • 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.

    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
previous month august 2008 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Go to today