Fwd: How does a binding know what it gets should be treated like an NSArray or not ? (Was: How to observe and bind (KVO/KVB) to a value generated at runtime..)
Fwd: How does a binding know what it gets should be treated like an NSArray or not ? (Was: How to observe and bind (KVO/KVB) to a value generated at runtime..)
- Subject: Fwd: How does a binding know what it gets should be treated like an NSArray or not ? (Was: How to observe and bind (KVO/KVB) to a value generated at runtime..)
- From: email@hidden
- Date: Sun, 26 Feb 2006 10:44:02 -0800
On 2006/02/26, at 6:06, Camillo Lugaresi wrote:
On 26/feb/06, at 06:43, Andre wrote:
On 2006/02/25, at 15:07, Camillo Lugaresi wrote:
On 25/feb/06, at 17:33, email@hidden wrote:
Does *anyone* know how to get an array into a table column or
NSArrayController using a plain array or array indexed accessors?
Use the contentArray binding or the setContent method of
NSArrayController.
Ok, yes this works, I don't know why I was having problems before.
I was binding contentArray to an object with indexed accessors,
for some bizarre reason it wasn't working right...
In any case, the main problem I'm still having is that if each
column is bound to a different base key path (even if the same
controller), then the second column doesn't know what to do
with the array its given and just prints the description of the
array..... this is the main problem I'm having. So I can't seem to
convince the table column to pull the items out into each row...
To exemplify here's some pics of the problem:
http://homepage.mac.com/son_gohan/Pic3.png
http://homepage.mac.com/son_gohan/Pic4.png
A table view is supposed to display the attributes of the items of
a list: each row is an item and each column is an attribute. If you
bind columns to different arrays, the table view can't tell if two
attributes belong to the same object, ie it can't tell which how to
group cells from different columns into a single row. So don't do
that: bind all columns through arrangedObjects instead.
Yea, thats exactly right. Its my mistake.
In general, it looks like you're making things harder for you than
they should be. It's not obvious why you would need a custom array
controller for that UI. This site has several examples of the
recommended way to do things: <http://homepage.mac.com/mmalc/
CocoaExamples/controllers.html>
Yes, your right, I was definitely making it much harder than it
needed to be.
In fact, one of the first places I went to for pointers was the page
you just mentioned (thanks to mmalc), but couldn't find the solution
to my specific problem there either.
As you may know (from previous posting), I was using proxy objects
returned from my array controller in a different key (instead of
arrangedObjects) and tying that key to a different column in a table
column; what I was seeing then was the column printing the same array
contents in every column. The reason I needed a proxy was that it
contained a value derived at runtime depending on the state of the
array controller (in a master detail interface and depending on which
object is the 'master' a certain value is derived for the model
object) so simply subclassing NSManagedObject is not enough because
it can never know what array its in or what array controller is
holding it because there can be many controllers holding a model
object at the same time....
So it turns out, my solution was standing in front of me the whole
time. Just let the proxy be a full proxy, not just for the derived
key value, but all key values of the wrapped object, and return an
array of managed objects wrapped in proxies from arrangedObjects.
Then I can bind the table view to all the keys from the same base key
path and get the results I wanted. It works perfectly.
I guess this is a lesson "don't fight the frameworks" just work with it.
Kudos to the designers of Key Value Coding and Key Value Binding,
its really wonderful to work with such a great design. It makes a lot
of solution simple.
Thanks again Camillo.
Andre
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden