Binding an NSNumber to an NSTableColumn

[BadWolf13]

Hi, not sure what I'm doing wrong, or if this just isn't supposed to be done, but I'm having issues binding the value of an NSTablecolumn to an NSNumber through an Array Controller. When the document loads, it displays the values in the table properly, but whenever I try to select a row in this table, it crashes with EXC_BAD_ACCESS.

Now I tried changing the Key Path in the bindings window of the table column to add ".doubleValue", whereby I can select the row without it crashing, but then it changes all the numbers on that row to 0.

Another table view in the same app has NSUInteger and double values, and that one works ok, it's just when there's an NSNumber involved that it crashes. Are we not supposed to use NSNumbers for binding table columns? It seems like Apple is encouraging us to stop using primitives, so I find that highly unlikely. Anyone got any thoughts?

[gnasher729]

Originally Posted by BadWolf13

Hi, not sure what I'm doing wrong, or if this just isn't supposed to be done, but I'm having issues binding the value of an NSTablecolumn to an NSNumber through an Array Controller. When the document loads, it displays the values in the table properly, but whenever I try to select a row in this table, it crashes with EXC_BAD_ACCESS.

Now I tried changing the Key Path in the bindings window of the table column to add ".doubleValue", whereby I can select the row without it crashing, but then it changes all the numbers on that row to 0.

Another table view in the same app has NSUInteger and double values, and that one works ok, it's just when there's an NSNumber involved that it crashes. Are we not supposed to use NSNumbers for binding table columns? It seems like Apple is encouraging us to stop using primitives, so I find that highly unlikely. Anyone got any thoughts?

1. Don't feel in any way encouraged to avoid primitives. Primitives (like double or int vs. NSNumber) are orders of magnitude faster to use, and a lot easier to use. The only reason to use NSNumber is in situations where objects are needed for whatever reason - for example to put things into dictionaries - which have the advantage to a struct that they are flexible and adaptable without code changes.

2. If an NSNumber "crashes" the reason is most likely that it has been released. For example [[NSNumber numberWithInteger:3000] will be an autoreleased object that gets destroyed when its autorelease pool goes away. (Except that in some cases it won't crash, which makes the problem harder to detect).

[BadWolf13]

What about bindings and KVO? I was under the impression that they work better with objects than with primitives?

For instance, this application, whenever the user changes the value in a text field, I want the filter predicate on an array controller to update automatically. Is this gonna work just as well if I bind my text field to a double, as opposed to an NSNumber?

[Sydde]

KVO works just fine with primitives – it is triggered by a setter function (which notifies to observer). If your array elements are compound objects, as they often are for tables, you can have KVC primitives no problem at all.

[jeanlain]

NSNumber should bind to a column's value just fine. You can use an NSNumber formatter in the table cell if you want.
I think your crash reflect another issue with an NSNumber object being deallocated while it still shows in the table. You can enable zombies in the run settings to see if messages are sent to deallocated instances.