Re: key value observing stops
Re: key value observing stops
- Subject: Re: key value observing stops
- From: Allan Odgaard <email@hidden>
- Date: Wed, 25 Feb 2004 00:36:10 +0100
On 24. Feb 2004, at 20:28, Francisco Tolmasky wrote:
Actually I do want setNeedsDisplay, since each cell's object value
remains the same, it's just internal data within each object that
changes. My custom NSCell basically draws three strings, each of the
strings is a value held by the cell's object value. Thus, when I
change the value of the object (for example by saying [theObject
setObject: @"new string" forKey: WellKnownKey]) all I need to do is
say setNeedsDisplay: YES for the information to be redisplayed.
Is this safe? I mean, doesn't NSTableView re-use the same cell for
different rows?
Have you verified that the problem is really with the missing bindings,
and not with this scheme? e.g. a table view which refuses to redraw
itself (or use cached values etc.).
Does the cell read the values directly from the model? since you only
need to redraw to get the updated values shown.
I don't want to reloadData since this would also probably rearrange
the objects (according to the sort descriptors) and I want the cell to
remain fixed in place until editing is complete, not bouncing around
as you type.
So values actually do change in the table view, but you do not want to
inform the table view that values have changed, but you want it to
redraw the new values nonetheless?
I btw think that the sorting should work just fine, unless the sort key
is being changed, but then, wouldn't the user expect the item to move?
of cause not while editing, but while editing, the field editor is up
and (speaking of experience) trying to interact too much with the table
view while this is happening is not a good idea. Could that perhaps be
the problem?
The text view is being used much in the same fashion as in address
book, which is why it sets specific values of my model class.
You could define multiple keys on the text view for which you send
will/didChangeValueForKey:.
It is generally best to have the view observable, because then you can
easily re-use it with other models -- likewise, changing the model does
not require a change to the view.
By using bind:toObject:withKeyPath:options: you can get exactly the
same effect as having the view set values in the model, i.e. when a
value in the view changes, it is set on the model object
(automatically), and keys can be virtual (i.e. the value generated on
demand), plus you can set a set of dependent keys (i.e. changing one
value will update several keys).
I hope that's a little clearer, it's kind of hard explaining it all.
I probably cannot be of much help to what the problem is, but I would
suggest making sure that it is really the binding which fails, i.e. by
inserting debug output from the observe method. Then try to copy the
value received by the model instead of retain (so that successive
notifications are guaranteed to be different (and thus not ignored)).
I also think having the model contained in an array controller is
something you should try to get rid off -- why can't you make the table
view observe the model itself?
Also, if you use setValue:forKey: or set<Key>: in your model then you
do not need to manually invoke will/didChangeValueForKey: -- you may
also want to implement corresponing getters. The binding system would
like to obtain the "old" value of the key so that it can cancel any
redundant set invocations, altough I would think it will just
uncritically set the values when there is no getter. Or perhaps you
already have a getter for the keys (and if so, check to see if this
could be the cause of your problems).
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.