Kyle gave the long answer.
But, if it isn’t documented, don’t count on it (although there is some backfill
required there).
Also, being KVO compliant doesn’t necessarily mean you can simply bind to it,
as you can’t be sure that the result will be returned on the main thread.
KVO compliance
Hi, I have some places in my code where I have managed objects that need to
observe various key paths. If one of these objects has been deleted by the
user, and then they undo, I need to re-establish the KVO.
As undo doesn't call awakeFromFetch, I need to do this somewhere else. I have
mechanisms other than KVO to keep your data model updated. KVO can be
a world of hurt when used the way you are using it. There are old threads on
this topic. See, for example, Strange
NSManagedObjectContextObjectsDidChangeNotification behavior.
Dave
On 2010-05-01, at 9:42 AM, Gideon King wrote
On Sat, May 1, 2010 at 9:34 AM, Dave Fernandes
dave.fernan...@utoronto.ca wrote:
If you are observing something that is not part of your data model, you might
try using mechanisms other than KVO to keep your data model updated. KVO can
be a world of hurt when used the way you are using
Thanks guys - will look into that.
On 02/05/2010, at 3:11 AM, Kyle Sluder wrote:
On Sat, May 1, 2010 at 9:34 AM, Dave Fernandes
dave.fernan...@utoronto.ca wrote:
If you are observing something that is not part of your data model, you
might try using mechanisms other than KVO to keep your
Gideon King (gid...@novamind.com) on 2010-05-01 09:42 said:
Hi, I have some places in my code where I have managed objects that need
to observe various key paths.
Why? (I'm curious... I've never used such a pattern.) Perhaps instead
you could override setters so that they perform other actions
It's inherited code from someone else, and am trying to work that out myself
too...luckily there are only 5-6 of them, so I should be able to sort it out.
Just looking at it now, I think a little refactoring should sort it out, and
remove the need for KVO.
On 02/05/2010, at 5:23 AM, Sean
I'm using KVO as a generalized recalculation engine, somewhat akin to how a
spreadsheet recalcuates values based on what's changed. It's mostly successful
once you eliminate cycles, but there is a persistent problem.
On each relevant object, I have
On Apr 21, 2010, at 17:47, Glen Low wrote:
I'm using KVO as a generalized recalculation engine, somewhat akin to how a
spreadsheet recalcuates values based on what's changed. It's mostly
successful once you eliminate cycles, but there is a persistent problem.
The likely answer (see below
much in the KVO documentation
about CGPoint or how I should expect to receive structs or other primitives.
This is iPhone OS (incase that makes a difference).
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests
getValue:oldPoint ]
Is this correct? I've failed to find anything much in the KVO documentation
about CGPoint or how I should expect to receive structs or other primitives.
In the case of NSPoint/CGPoint:
CGPoint oldPoint = [oldValue pointValue];
This is iPhone OS (incase that makes a difference
]
Is this correct? I've failed to find anything much in the KVO documentation
about CGPoint or how I should expect to receive structs or other primitives.
In the case of NSPoint/CGPoint:
CGPoint oldPoint = [oldValue pointValue];
This is iPhone OS (incase that makes a difference
the CGPoint from it
CGPoint oldPoint;
id oldValue = [ change valueForKey:NSKeyValueChangeOld ];
[ (NSValue*)oldValue getValue:oldPoint ]
Is this correct? I've failed to find anything much in the KVO documentation
about CGPoint or how I should expect to receive structs
Hello all.
Im implementing a live filter, and each, time I insert a filter in the
filterDictionary the controller (which is another class) gets notified about
the insertion.\
I was reading the KVO, and its says something about NSKeyValueChangeKindKey.
So this is what Im doing in the Controller
, it is always best to post the crash report.
Well, I wrote a workaround, so I can't give you a crash report anymore.
The crash happens in the KVO unregistering routine.
The problem is that when the represented object is removed from the array
controller, the corresponding NSView is not immediately
the NSView
slowly fade away. Net result is that the NSView survives some tenths of a
second after the represented object is released, and the KVO unregistering
crashes.
Hooray for retain cycles; if you avoid them you get overrelease bugs!
(I can't wait for garbage collection.)
This happens a lot
is linked to a
NSCollectionView. The NSView I use to visually represent the NSArrayController
contents includes a slider that observes a parameter of C (more specifically,
opacity) through KVO.
So far, so good.
I have a NSButton in C to remove from the array controller the A object it
represents
On Jan 22, 2010, at 7:01 AM, vincent habchi wrote:
I have a NSButton in C to remove from the array controller the A object it
represents. However, each time I click on that button, I first get a warning
telling me that I remove an observed object before releasing the observer,
and then
On Jan 10, 2010, at 11:18 PM, Dave Fernandes wrote:
Look for Cocoa Bindings Guide in the docs. It would be nice if it were
cross-referenced in every class description.
Please file a bug about that.
Class methods that are KVO compatible are stated as such in the reference. They
aren’t
On Jan 10, 2010, at 19:58, Jerry Krinock wrote:
After studying some about bindings during the last week, I decided that, just
for fun, I would bind an NSSegmentedControl to its window controller using a
binding instead of target/action. I thought that selectedSegment might be a
KVO
that change
data flows in the *opposite* direction of the *to*. That is, if I bind myself
*to* you, I observe what you do and your changes flow back *to* me.
I wonder why bindings was not as an extension of KVO, instead of as a separate
sideshow. The effect is the same as KVO
. Now I know that a binding is only one way, and further that change
data flows in the *opposite* direction of the *to*. That is, if I bind
myself *to* you, I observe what you do and your changes flow back *to* me.
I wonder why bindings was not as an extension of KVO, instead
On 2010 Jan 11, at 09:46, Mike Abdullah wrote:
I wonder why bindings was not as an extension of KVO, instead of as a
separate sideshow. The effect is the same as KVO, with the addition that a
designated setter is automatically invoked in the observer when a change is
observed.
What
On Jan 11, 2010, at 9:01 am, Jerry Krinock wrote:
I wonder why bindings was not as an extension of KVO, instead of as a
separate sideshow. The effect is the same as KVO,
It's not at all. Bindings uses KVO to ensure that things are kept
synchronised; KVO is a general mechanism that allows
On Jan 11, 2010, at 10:04, Jerry Krinock wrote:
Well, I guess I'm talking about the default implementation then. I just mean
I'd probably have an easier time learning bindings if they were called maybe
KVO Plus, and somehow used a class' regular properties on both ends of a
binding
After studying some about bindings during the last week, I decided that, just
for fun, I would bind an NSSegmentedControl to its window controller using a
binding instead of target/action. I thought that selectedSegment might be a
KVO-compliant property of NSSegmentedControl because it has
bindings during the last week, I decided that, just
for fun, I would bind an NSSegmentedControl to its window controller using a
binding instead of target/action. I thought that selectedSegment might be a
KVO-compliant property of NSSegmentedControl because it has a
-selectedSegment
doesn't catalogue KVO compliance, it lists
bindings.
In general, controller objects observe model objects, and views observe
controllers and models -- you typically don't bind to views. Thus you shouldn't
generally expect views' properties to be observable.
mmalc
Hi,
Sorry if this has been posted before; I did a quick scour but might not have
used the right keywords (this issue isn't very general).
Basically I'm noticing that when I expect KVO observations to be triggered,
they aren't. Most likely this is due to my misunderstanding, but I'd like to
post
On Dec 11, 2009, at 09:10, Steven Degutis wrote:
[reformatted to be less annoying]
// when this is called, the KVO in SDObject is triggered with an empty array
[object bind:@content toObject:controller2 withKeyPath:@arrangedObjects
options:nil];
NSLog(@mark 2);
Yeah, well, at this point
On Dec 8, 2009, at 4:35 PM, Greg Parker wrote:
Which OS version is this? 10.6.2 fixed a performance problem with garbage
collection and large KVO populations. If you still have trouble in 10.6.2+
then you should file a bug report.
On Dec 8, 2009, at 6:38 PM, Rob Keniger wrote:
Please see
to spend far too much time fighting with
NSTreeController/NSArrayController trying to get real world reliable
performance out of them.
I think the bindings + KVO technology is great but with GC, at least, it seems
easy to contrive a demon. 10.6 especially seems rather toxic.
Maybe it's time to back off
in the
auto zone.
The only references to some of these key function names I could find on the web
were in the libauto sources, and no mention at all in mailing lists, so it
doesn’t seem like anybody else has posted about this before.
Any ideas about why NSTreeController’s KVO is taking up so much memory
Any ideas about why NSTreeController’s KVO is taking up so much memory/CPU
with bookkeeping? Any suggestions for working around the problem?
I assume that you are using bindings. Looks like a typical KVO notification
storm to me.
What works well for adding and updating one or two
On Dec 8, 2009, at 2:44 PM, jonat...@mugginsoft.com wrote:
Any ideas about why NSTreeController’s KVO is taking up so much memory/CPU
with bookkeeping? Any suggestions for working around the problem?
I assume that you are using bindings.
Yes.
Looks like a typical KVO notification storm
, it’s happening after all of the actual, real work is done.
Which OS version is this? 10.6.2 fixed a performance problem with garbage
collection and large KVO populations. If you still have trouble in 10.6.2+ then
you should file a bug report.
--
Greg Parker gpar...@apple.com Runtime
On 09/12/2009, at 7:35 AM, Greg Parker wrote:
Which OS version is this? 10.6.2 fixed a performance problem with garbage
collection and large KVO populations. If you still have trouble in 10.6.2+
then you should file a bug report.
There are still massive remaining performance issues
On Nov 18, 2009, at 5:06 PM, Sean McBride wrote:
On 11/18/09 9:00 AM, Corbin Dunn said:
Oh -- another thing. Does your subclass of NSCollectionView override:
(void)viewWillMoveToWindow:(NSWindow *)window {
but not call super? If not... call super! Your classes should always
call super
0x1ab6ad40: Observer: 0x19427a80, Key path:
firstResponder, Options: New: YES, Old: NO, Prior: NO Context: 0x0,
Property: 0x4453e60
)
I looked at what the observer object's class is, and it's a subclass of
NSCollectionView. We do not explicitly setup a KVO relationship for
firstResponder. I
On Nov 17, 2009, at 2:04 PM, Aaron Clarke wrote:
Even if it doesn't crash, closing the NSWindow always results in the
following error message.
An instance 0x11b75230 of class MyWindow was deallocated while key value
observers were still registered with it. Observation info was leaked, and
: 0x0,
Property: 0x4453e60
)
I looked at what the observer object's class is, and it's a subclass of
NSCollectionView. We do not explicitly setup a KVO relationship for
firstResponder. I also noticed that the Application Kit Release Notes for
Snow Leopard mention that firstResponder is KVO
: 0x0,
Property: 0x4453e60
)
I looked at what the observer object's class is, and it's a subclass of
NSCollectionView. We do not explicitly setup a KVO relationship for
firstResponder. I also noticed that the Application Kit Release Notes for
Snow Leopard mention that firstResponder is KVO
On 11/18/09 9:00 AM, Corbin Dunn said:
Oh -- another thing. Does your subclass of NSCollectionView override:
(void)viewWillMoveToWindow:(NSWindow *)window {
but not call super? If not... call super! Your classes should always
call super if it is defined in a superclass, unless you have a good
, Old: NO, Prior: NO Context: 0x0,
Property: 0x4453e60
)
I looked at what the observer object's class is, and it's a
subclass of
NSCollectionView. We do not explicitly setup a KVO relationship for
firstResponder. I also noticed that the Application Kit Release
Notes for
Snow Leopard mention
Aaron Clarke (clark...@gmail.com) on 2009-11-18 8:28 PM said:
Oh -- another thing. Does your subclass of NSCollectionView override:
(void)viewWillMoveToWindow:(NSWindow *)window {
but not call super? If not... call super! Your classes should always
call super if it is defined in a
a subclass of
NSCollectionView. We do not explicitly setup a KVO relationship for
firstResponder. I also noticed that the Application Kit Release Notes for
Snow Leopard mention that firstResponder is KVO-compliant, which makes me
believe this is something new in Snow Leopard. All
Hi all,
I have sevral objects of different kind that observe values on each
other.
Now, when the objects are being released, I get an exception from the
KVO stuff telling me that an object is being deallocated while still
observed. And that's justified. Yet, the problem is in whatever
:
Hi all,
I have sevral objects of different kind that observe values on each
other.
Now, when the objects are being released, I get an exception from the
KVO stuff telling me that an object is being deallocated while still
observed. And that's justified. Yet, the problem
I have a managed object context with two attached NSObjectControllers
in entity mode. Both controllers control the same entity.
managed object model
nib 1
controller
user interface
bind in interface builder
nib 2
controller
user interface (custom view)
On Nov 4, 2009, at 6:04 AM, Richard Somers
rsomers.li...@infowest.com wrote:
I have a managed object context with two attached
NSObjectControllers in entity mode. Both controllers control the
same entity.
Important: do you really mean entity, or do you mean managed object?
managed
On Nov 4, 2009, at 9:40 AM, Kyle Sluder wrote:
Nib 2 only partly works. Changes made in the custom view do not
show up in the managed object model or in the user interface found
in nib 1.
So now we also need to see your custom view code.
Here is the code for nib 2 which only partly
before, the default NSObject bindings
implementation only set up KVO in one direction. If you call -[myView
bind:@num toObject:myController withKeyPath:@someModelKeyPath
options:0], KVO will only occur from [myController].someModelKeyPath
-- [myView].num. NSObject doesn't (and can't) also set up
On Nov 4, 2009, at 3:17 PM, Richard Somers wrote:
@interface MyView : NSView
{
double num;
}
@end
@implementation MyView
- (double)num
{
return num;
}
- (void)setnum:(double)newNum
{
[self willChangeValueForKey:@num];
num = newNum;
[self didChangeValueForKey:@num];
}
On Nov 4, 2009, at 2:31 PM, Kyle Sluder wrote:
This invokes the default implementation of -
bind:toObject:withKeyPath:options:, which takes care of the model -
view communication. You now need to take care of the view - model
communication. As described in the User Updates a Value in the
On 05/11/2009, at 8:42 AM, Richard Somers wrote:
See mmalc’s Graphics Bindings sample:
http://homepage.mac.com/mmalc/CocoaExamples/controllers.html
Sometimes Cocoa can be overwhelming. This will help. Thank you so
much. :)
You might also find this blog post very helpful:
On Nov 4, 2009, at 5:20 pm, Rob Keniger wrote:
See mmalc’s Graphics Bindings sample:
http://homepage.mac.com/mmalc/CocoaExamples/controllers.html
Sometimes Cocoa can be overwhelming. This will help. Thank you so much. :)
You might also find this blog post very helpful:
On 11/2/09 12:58 PM, Ben Trumbull said:
This doesn't really have anything to do with Core Data. However, for
NSManagedObject, Core Data already provides the change coalescing and
NSNotifications for you. You can respond within
NSManagedObjectContextObjectsDidChangeNotification instead.
So I
What is considered best practice when it comes to mutating many
properties of a managed object, specifically with regard to KVO
observers getting notified before all mutations are finished?
This is a problem intrinsic to the design of KVO. KVO is all about fine
grained per property
to an invalid
intermediate state is a more reasonable problem to consider, but it
normally shouldn't matter either. Normally KVO will be used to update
your UI and/or maintain undo. You mention Core Data so that will
handle undo for you but even if you were doing that yourself it
shouldn't matter. Undo
On 11/2/09 12:58 PM, Ben Trumbull said:
What is considered best practice when it comes to mutating many
properties of a managed object, specifically with regard to KVO
observers getting notified before all mutations are finished?
This is a problem intrinsic to the design of KVO. KVO is all
If your issue is that drawing or recalculation is occurring too
frequently after KVO changes, you can consider coalescing and deferring
the observers' actions instead of performing them synchronously. This
can be valuable even for less complex KVO issues.
You could also refactor the 3
Hi all,
What is considered best practice when it comes to mutating many
properties of a managed object, specifically with regard to KVO
observers getting notified before all mutations are finished?
Let's say I have an Rectangle object. It has properties: colour, width,
height. Imagine some
On 31/10/2009, at 9:01 AM, Sean McBride wrote:
Hi all,
What is considered best practice when it comes to mutating many
properties of a managed object, specifically with regard to KVO
observers getting notified before all mutations are finished?
In situations like these I personally tend
problem to consider, but it
normally shouldn't matter either. Normally KVO will be used to update
your UI and/or maintain undo. You mention Core Data so that will
handle undo for you but even if you were doing that yourself it
shouldn't matter. Undo will record each property change and group
.
KVO doesn't have an easy way to observe a collection's contents, so
the NSNotification approach is your best bet.
- (void)awakeFromFetch {
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(managedObjectContextDidChange:) name
Hi all.
I am working on a Core Data application which contains an entity that
needs to be notified of changes in entities that it has a relationship
to. Let's talk about this in terms of Apple's example with Departments
and Employees. As described here
On 3 Oct, 2009, at 23:51, Klaus Backert wrote:
On 3 Oct 2009, at 22:06, Colin Howarth wrote:
If you use dot notation and properties, you are using the -value
and -setValue: accessor methods, which is KVC compliant and means
that KVO bits will get notified, no?
No.
From the documentation
Am 09.09.2009 um 11:02 schrieb John Chang:
No, it's a singleton. Basically it's a manager object that wants
to continually monitor something else for changes. Also, -
addObserver is the last line of code in -init, before the return.
This article may be of interest to you:
with the
NSKeyValueObservingOptionInitial option, which causes KVO to make a
bunch of calls to user code (with potentially lots of side effects)
directly inside -addObserver:etc:etc:. So the afterDelay: idea
wouldn't really help, since in both cases -addObserver: is going to be
catching and rethrowing exceptions. (One of our
On 2009 Sep 11, at 05:55, John Chang wrote:
Just to update you guys. We managed to reproduce the problem in-
house and
catch it in the debugger.
I'd be interested to know how John is going to fix this problem. I
myself have used the performSelector:withObject:afterDelay:0.0
solution in
0x00a258de in -[NSObject(NSKeyValueObserverRegistration)
addObserver:forKeyPath:options:context:] ()
The ah-ha is that KVO is catching and re-throwing exceptions in
-addObserver:.. If one sets a breakpoint in the code that gets called
indirectly, you'll get something much more interesting
On 08/09/2009, at 12:36 AM, John Chang wrote:
Hi all,
Question: is it unsafe for some reason to be adding yourself as a KVO
observer during -init?
We have a singleton with an -init that looks something like this:
- (id)init
{
if ((self = [super init]))
{
_foo = [[NSMutableDictionary alloc
the observer is causing this exception?
There's nothing KVO related in this message.
Sorry, I was thinking of including the backtrace and I guess I didn't.
In -init, -addObserver: is only called once, so we're pretty certain
about the exact line of code that is being indicated here, unless
On 9 sep 2009, at 11.21, Mike Abdullah wrote:
Well I would question why you're calling +[XYZManager sharedManager]
from within -[XYZManager init] like that. What if you change your
init routine to:
Oops, sorry. It's actually two different classes which I renamed
incorrectly for the
On 9 Sep 2009, at 10:31, John Chang wrote:
On 9 sep 2009, at 11.21, Mike Abdullah wrote:
Well I would question why you're calling +[XYZManager
sharedManager] from within -[XYZManager init] like that. What if
you change your init routine to:
Oops, sorry. It's actually two different
a system-generated class which has its own KVO setup,
or you subclass something you wrote last year and something which
relies on KVO stops working and you've often torn half your code apart
before you find it.
What do I use. Normally a class static, provided that's granular
enough
() method
(taking care again to check I'm not being called for a subclass) and stuff
into a static I kept for the
purpose.
Personally, for my KVO contexts, I use:
static void *const MyClass_KVOContext = (void *)MyClass_KVOContext;
I've never seen anyone else use it, but I find
On 9 Sep 2009, at 11:21, Dave Keck wrote:
static void *const MyClass_KVOContext = (void *)MyClass_KVOContext;
That certainly is unusual, I use the following macro:
#define NSSTRING_CONTEXT(var) static NSString *var = @#var
then use the address of the identifier passed as var. This has the
We have a singleton with an -init that looks something like this:
- (id)init
{
if ((self = [super init]))
{
_foo = [[NSMutableDictionary alloc] init];
_bar = [[NSMutableDictionary alloc] init];
[[XYZManager sharedManager] addObserver:self forKeyPath:@allObjects
What about writing a method, -finishSetup, and invoke it with a
delay like below? I use this pattern a lot with loading views. It
seems like it would work so that you add observation when your
object is ready.
Marc
[self performSelectorOnMainThread:@selector(finishSetup)
I've just tested it on Snow Leopard (10a380), and it works as expected.
Do you happen to remember the technical reasons why KVO on DOs would fail?
Ed
On Mon, Sep 7, 2009 at 11:55 PM, Scott Anguishsc...@cocoadoc.com wrote:
In spite of the fact that it might be working, it isn't supported
On Sep 8, 2009, at 10:38 AM, Edward Chan wrote:
I've just tested it on Snow Leopard (10a380), and it works as
expected.
Perhaps. But as I said, unsupported, untested internally, and could
break at any time.
Do you happen to remember the technical reasons why KVO on DOs would
fail
Hi all,
Question: is it unsafe for some reason to be adding yourself as a KVO
observer during -init?
We have a singleton with an -init that looks something like this:
- (id)init
{
if ((self = [super init]))
{
_foo = [[NSMutableDictionary alloc] init];
_bar = [[NSMutableDictionary alloc] init
On Sep 7, 2009, at 21:45 , Edward Chan wrote:
Great...
How long ago did you ask the Apple engineers? I haven't tried this
piece of code with Snow Leopard actually...
This was back in February, I was probably testing on Leopard. The
difference between what you and I tried was that I used -
On Sep 7, 2009, at 20:02 , Edward Chan wrote:
Hello,
I'm using KVO on a Distributed Object, and I am binding my UI controls
based on the observer.
Hi,
not much of constructive help from me I'm afraid, just a warning. I
also did the same thing once, and the reaction from Apple engineers
John Chang wrote:
Hi all,
Question: is it unsafe for some reason to be adding yourself as a KVO
observer during -init?
We have a singleton with an -init that looks something like this:
- (id)init
{
if ((self = [super init]))
{
_foo = [[NSMutableDictionary alloc] init];
_bar
exception 'NSInvalidArgumentException', reason: '***
-[NSCFDictionary setObject:forKey:]: attempt to insert nil key'
Why do you think registering the observer is causing this exception?
There's nothing KVO related in this message.
___
Cocoa-dev mailing
On 08/09/2009, at 12:36 AM, John Chang wrote:
Hi all,
Question: is it unsafe for some reason to be adding yourself as a KVO
observer during -init?
We have a singleton with an -init that looks something like this:
- (id)init
{
if ((self = [super init]))
{
_foo = [[NSMutableDictionary alloc
? If so, -observeValueForKeyPath:
is getting called on them before they've done their work in init.
-Ken
On Mon, Sep 7, 2009 at 7:36 AM, John Chang john.r.ch...@gmail.com wrote:
Hi all,
Question: is it unsafe for some reason to be adding yourself as a KVO
observer during -init?
We have
Hello,
I'm using KVO on a Distributed Object, and I am binding my UI controls
based on the observer.
For example:
MonkeyViewController.isEatingABanana - Binded to a UI checkbox.
MonkeyViewController.m:
@propery (readwrite, assign) BOOL isEatingABanana;
-(id)init {
...
[MonkeyBrainDOObject
Great...
How long ago did you ask the Apple engineers? I haven't tried this
piece of code with Snow Leopard actually...
On Mon, Sep 7, 2009 at 3:29 PM, Graham Leel...@thaesofereode.info wrote:
On Sep 7, 2009, at 20:02 , Edward Chan wrote:
Hello,
I'm using KVO on a Distributed Object, and I
, Graham Leel...@thaesofereode.info wrote:
On Sep 7, 2009, at 20:02 , Edward Chan wrote:
Hello,
I'm using KVO on a Distributed Object, and I am binding my UI controls
based on the observer.
Hi,
not much of constructive help from me I'm afraid, just a warning. I also did
the same thing
In spite of the fact that it might be working, it isn't supported.
When I talked to engineering about this, this is what I was told. He
was a bit shocked it worked at all, and it isn't tested as part of
releases.
On Sep 7, 2009, at 3:02 PM, Edward Chan wrote:
Hello,
I'm using KVO
On Sep 7, 2009, at 4:45 PM, Edward Chan wrote:
Great...
How long ago did you ask the Apple engineers? I haven't tried this
piece of code with Snow Leopard actually...
It still isn't supported in SL. I'd be shocked if it ever is.
___
Cocoa-dev
: yourself, nor
construct change dictionaries. When a property changes in a way
that KVO can't automatically track, you are supposed to call -will/
didChangeValueForKey: (or the corresponding will/didChange...
methods for set or array mutation) and KVO will generate the change
notification
on the
information in the change dictionary. If you were using will/
didChange..., then KVO can be expected to invoke valueForKey: on
the object whose property is changing, but that's not what (you
say) you're doing.
Thanks. That was helpful. On 10.5 the receiver *does* apparently
We've got an app that is using keyValueForPath: and
observeValueForKeyPath:ofObject:change:context: to keep a status window
up-to-date.
On 10.5 it works fine. On 10.6 keyValueForPath: is called exactly once
per property. When we later create a change dictionary and send
On Tue, Sep 1, 2009 at 5:14 PM, Kevin Brockap...@kevin.com wrote:
We've got an app that is using keyValueForPath: and
observeValueForKeyPath:ofObject:change:context: to keep a status window
up-to-date.
It's valueForKeyPath:.
On 10.5 it works fine. On 10.6 keyValueForPath: is called exactly
Hi,
In my program, I rely heavily on key-value observing (KVO), which I
find really useful. However, I haven't found a good way to know when I
should stop observing, i.e. call removeObserver:forKeyPath:.
Until now, my solution has been to start observing in the designated
initialiser
If you're targeting 10.6 only, this is taken care of you automatically
according to the Foundation release notes. Any KVO observers will be
automagically removed as observers by the runtime, and thus you won't have
to do it at all. The release notes hint that the appropriate solution for
10.5
301 - 400 of 667 matches
Mail list logo
