Re: View based table binding to alternate object?
Re: View based table binding to alternate object?
- Subject: Re: View based table binding to alternate object?
- From: Quincey Morris <email@hidden>
- Date: Tue, 11 Aug 2015 19:44:17 +0000
On Aug 11, 2015, at 11:29 , Jim Thomason <email@hidden> wrote:
>
> Incredibly, this works. Changing it to an invalid key path ("C") tosses an exception immediately that the staticObject is not key-value coding compliant for key C. Leaving it as B (the valid path) will toss no errors, but won't actually update the view.
>
> I'll see if I can dig into tableView:viewForTableColumn:row: to find any answers - but keep in mind, this is all bindings related. I haven't used any delegate or datasource methods as of yet to do anything.
Yes, but this isn’t that. The binding between a table view and its content, on the one hand, is unrelated to the bindings between cell subviews and the properties they depend on, on the other hand. The two systems are glued together by the ‘objectValue’ object, but they’re otherwise unrelated, at least conceptually.
In your scenario, you’re only concerned with cell subview bindings, which on the face of it ought to be bindable to any normal bindings target. The only strange thing is the timing — a cell’s subview bindings need to be established when the cell is re-used, not when the cell is unarchived from its nib. It’s possible that this has some side effect.
Or, it could be something truly unrelated, like objectController.selection being nil. Or like some property not being properly KVO-compliant.
> And I agree completely that this is not the right approach to take. I was doing some quick prototyping and wired up what would eventually be a dynamically populated button to a static object, just so I could get a value in to test with quickly, and in the process I descended down this entire rabbit hole. As best as I can tell, wiring up the view to something returned from the array controller's arrangedObjects would resolve the issue entirely. I doubt this would be something that'd come up in production.
>
> So it's an odd issue that only seems to manifest under odd circumstances and is easily coded around. It's just one of those things that catches my interest in trying to find out if it's intentionally done this way for some reason, or indicative of a bug. I'm leaning towards bug.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden