Actually, I did put in the NSLOG’s in the shouldEditTableColumn and it never
“fired” no matter what I did, hence my question about the need and where
documented.
I did find in the docs the statement to the effect that setObjectValue, as a
datasource method, can run without the other datasource methods and with
bindings.
The other I cannot find in the docs. You would think that these intertwined
relationships would be set out in the docs in a tidy fashion.
On Feb 17, 2015, at 3:51 PM, Quincey Morris
<quinceymor...@rivergatesoftware.com> wrote:
> On Feb 17, 2015, at 12:35 , John MacMullin <john.macmul...@cox.net> wrote:
>>
>> So it appears that I don’t need shouldEditTableColumn because of the
>> bindings. Where is this in the docs? (rather than random cocoa sources).
>
> I’m not sure it’s got anything to do with bindings. Configuring table views
> is just a bit messy, probably because they’ve evolved so much over the years.
>
> If the delegate method is absent, then I’d expect the “Editable” checkbox on
> the table column in IB to control the behavior. It’s certainly possible that
> some bindings options may further restrict editability, and if you have a
> NSArrayController between the table and its data model, it may also have
> settings that affect editability.
>
> The delegate method is likely intended to cover cases where the editability
> is determined per-row, or by some other factor that isn’t easy to express in
> IB, array controllers or bindings.
>
>> If I take out the following:
>>
>> - (BOOL)tableView:(NSTableView *)tableView shouldSelectRow:(NSInteger)row
>> {
>> if (tableView) {
>> if (row >=0) {
>> return YES;
>> }
>> }
>> return YES;
>> }
>>
>> I can’t select any row. So it would appear that some of the table view
>> methods operate independently of the bindings. Where is this documented?
>
> It shouldn’t be necessary to have this method just to enable selection, and
> it’s got nothing to do (intrinsically) with bindings. You’ve got some other
> problem that’s interfering.
>
> For example, if you have the table’s “selected row indexes” binding bound to
> a property that doesn’t actually save the selection persistently, it’ll seem
> like selection doesn’t work (though in such a hypothetical scenario, it is
> working, but just getting cleared later, before you notice).
>
> Tracking down misbehaviors in table views can be painful, because there are
> lots of places to check, and no clear indication of what to look for.
> Generally, you just need to persevere, perhaps with some judicious NSLogging
> to check your assumptions about what’s happening and when.
Best regards,
John MacMullin
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
