Re: KVO - deallocation with observers attached

[Jonathan Mitchell]

> On 1 Jun 2017, at 00:51, Ken Thomases  wrote:
> 
> On May 31, 2017, at 5:02 PM, Jonathan Mitchell  wrote:
>> 
>> It is common for deallocating objects to abort if they have observers still 
>> registered.
>> 
>> The Data_Test object is deallocated with non nil -observationInfo and yet it 
>> does not abort.
>> Why does this occur?
> 
> It's not clear to me that the KVO machinery is obligated to set 
> observationInfo to nil when an object is no longer being observed.  Note that 
> observationInfo is *not* an object pointer.  It's a pointer to void.  Among 
> other things, that means that there's no memory management involved in the 
> setter.  That is, it's not a strong reference or even a weak one.  So, for 
> example, it's not necessary for KVO to nil it out to free memory.

Thanks for the input.
I wasn’t able to get to the bottom of this despite poking around with Hopper 
through the foundation framework.
There is an NSKVODeallocate foundation function that can get called when an 
observed object gets deallocated.
It raises the familiar KVO exception if -observationInfo is not nil.

- observationInfo does return a void* but it dereferences to an 
NSKeyValueObservationInfo :  NSObject instance.
Its obviously private API though.

I was able to track the comings and goings of NSKeyValueObservationInfo using 
the memory graph debugger and malloc stack logging but enlightenment did not 
strike.

I was able to make my test project behave as I anticipated but my real world 
app doesn’t seem so compliant.

I am just trying to eradicate the possibility of crashes that occur when the 
observing object deallocs and the observed object keeps pumping notifications 
to the old observers address.

Thanks

J

___

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

Re: KVO - deallocation with observers attached

[Ken Thomases]

On May 31, 2017, at 5:02 PM, Jonathan Mitchell  wrote:
> 
> It is common for deallocating objects to abort if they have observers still 
> registered.
> 
> However in some cases it seems that an object can get deallocated with 
> observers attached and not abort.
> 
> I have instrumented my test case thoroughly and overridden 
> -setObservationInfo: to log the observation changes as below.
> 
> The Data_Test object is deallocated with non nil -observationInfo and yet it 
> does not abort.
> Why does this occur?

It's not clear to me that the KVO machinery is obligated to set observationInfo 
to nil when an object is no longer being observed.  Note that observationInfo 
is *not* an object pointer.  It's a pointer to void.  Among other things, that 
means that there's no memory management involved in the setter.  That is, it's 
not a strong reference or even a weak one.  So, for example, it's not necessary 
for KVO to nil it out to free memory.

That also means that you should not be logging the observationInfo as though it 
were an object (using the "%@" format specifier or otherwise sending the 
-description message to it).  As mentioned in the observationInfo docs, 
"Overrides of this property must not attempt to send messages to the stored 
data."

By the way, does your override just log and call through to super?  Or did you 
actually implement storage in an instance variable?  If you did the latter, 
it's conceivable that you changed whether or not crashes are likely to follow 
deallocation with observers.  That's because the observationInfo would not be 
stored in a global look-aside table such that it could get accidentally 
attached to an unrelated object that happened to be allocated at the same 
address.

> I am sorting through some observer related crash reports just trying to 
> figure out possible causes.

I would think you'd have better luck logging the addition and removal of 
observers looking for an imbalance.

Regards,
Ken

___

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

Re: KVO question

[Gerd Knops]

One possible issues is that `self.thingy=x;` will trigger two change 
notifications for `thingy`: one for `self.dictionaryOfThings = temp;` (due to 
keyPathsForValuesAffectingThingy), and one when the setter exits. Depending one 
what your observer does this may have unforeseen side effects. 

A possible workaround would be to replace `self.dictionaryOfThings = temp;` 
with `_dictionaryOfThings = temp;`.

Gerd


> 
> On Nov 17, 2015, at 19:18, Graham Cox  wrote:
> 
> I’m using KVO to observe a bunch of properties.
> 
> Most of these properties are split out into simple things that set a single 
> value, but internal to my object, some end up setting a common dictionary of 
> attributes, which is also a property.
> 
> I KVO observe both the simple properties and the common dictionary property. 
> Mostly this is working, but when code directly sets the dictionary property, 
> the other properties don’t trigger their observers, even though I’m 
> implementing the +keyPathsForValuesAffecting, which I believe 
> should cause the additional triggering. Have I understood that right?
> 
> Here’s the kind of code I have:
> 
> 
> @property (retain) id thingy;
> @property (retain) NSDicitonary* dictionaryOfThings;
> 
> @implementation
> 
> - (void)   setThingy:(is thing
> {
>   NSMutableDictionary* temp = [self.dictionaryOfThings mutableCopy];
>   [temp setObject:thing forKey:kThingKey];
>   self.dictionaryOfThings = temp;
> }
> 
> - (id) thingy
> {
>   return [self.dictionaryOfThings objectForKey:kThingKey];
> }
> 
> 
> + (NSSet*)  keyPathsForValuesAffectingThingy
> {
>   return [NSSet setWithObject:@“dictionaryOfThings”];
> }
> 
> 
> So what I want (expect?) is that is code sets -dictionaryOfThings directly, 
> an observer of ‘thingy’ will be triggered. Is that right?
> 
> 
> —Graham
> 
> 
> 
> ___
> 
> 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/gerti-cocoadev%40bitart.com
> 
> This email sent to gerti-cocoa...@bitart.com


___

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

Re: KVO question

[Ken Thomases]

On Nov 17, 2015, at 7:18 PM, Graham Cox  wrote:
> 
> I’m using KVO to observe a bunch of properties.
> 
> Most of these properties are split out into simple things that set a single 
> value, but internal to my object, some end up setting a common dictionary of 
> attributes, which is also a property.
> 
> I KVO observe both the simple properties and the common dictionary property. 
> Mostly this is working, but when code directly sets the dictionary property, 
> the other properties don’t trigger their observers, even though I’m 
> implementing the +keyPathsForValuesAffecting, which I believe 
> should cause the additional triggering. Have I understood that right?

If by "code directly sets the dictionary property", you mean always in a 
KVO-compliant manner, then yes.


> @property (retain) id thingy;
> @property (retain) NSDicitonary* dictionaryOfThings;

It's not clear if this is a public or private property.  If it's public, and 
probably even if it's private, this should be a "copy" property, not just 
"retain".  If it's just "retain", you're not protected against somebody setting 
it to a mutable dictionary and then subsequently mutating the dictionary, 
thereby effectively mutating your property in a non-KVO-compliant manner.

All of that said, I agree with Quincey.  You should just use either normal 
properties backed by (compiler-synthesized) instance variables, or you can use 
a secondary object with such properties.  Using a dictionary may seem like a 
quick-and-dirty solution, but invites problems in the long run.

Regards,
Ken


___

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

Re: KVO question

[Alex Zavatone]

Are you implying that one KVO is blocking the others?

Sent from my iPhone

> On Nov 17, 2015, at 8:18 PM, Graham Cox  wrote:
> 
> I’m using KVO to observe a bunch of properties.
> 
> Most of these properties are split out into simple things that set a single 
> value, but internal to my object, some end up setting a common dictionary of 
> attributes, which is also a property.
> 
> I KVO observe both the simple properties and the common dictionary property. 
> Mostly this is working, but when code directly sets the dictionary property, 
> the other properties don’t trigger their observers, even though I’m 
> implementing the +keyPathsForValuesAffecting, which I believe 
> should cause the additional triggering. Have I understood that right?
> 
> Here’s the kind of code I have:
> 
> 
> @property (retain) id thingy;
> @property (retain) NSDicitonary* dictionaryOfThings;
> 
> @implementation
> 
> - (void)   setThingy:(is thing
> {
>NSMutableDictionary* temp = [self.dictionaryOfThings mutableCopy];
>[temp setObject:thing forKey:kThingKey];
>self.dictionaryOfThings = temp;
> }
> 
> - (id) thingy
> {
>return [self.dictionaryOfThings objectForKey:kThingKey];
> }
> 
> 
> + (NSSet*)  keyPathsForValuesAffectingThingy
> {
>return [NSSet setWithObject:@“dictionaryOfThings”];
> }
> 
> 
> So what I want (expect?) is that is code sets -dictionaryOfThings directly, 
> an observer of ‘thingy’ will be triggered. Is that right?
> 
> 
> —Graham
> 
> 
> 
> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.com

___

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

Re: KVO question

[Quincey Morris]

On Nov 18, 2015, at 16:29 , Roland King  wrote:
> 
> I didn’t read his original question as saying that

I could easily have got it wrong, but I believe what he was saying was that 
much of his system was working. The part that doesn’t work is when (e.g.) the 
Font Manager updates the dictionary directly, by which I mean it changes values 
in the dictionary, but does not replace the entire dictionary in the model 
object (it can’t do that, it doesn’t know where to find the model object, or 
what the property name of the dictionary in the model object is).

In this kind of update, Graham is expecting a KVO notification “for the 
dictionary”, in order to trigger 
___

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

Re: KVO question

[Roland King]

> On 19 Nov 2015, at 08:38, Quincey Morris 
>  wrote:
> 
> (sorry, posted the incomplete message by accident)
> 
> On Nov 18, 2015, at 16:29 , Roland King  > wrote:
>> 
>> I didn’t read his original question as saying that
> 
> I could easily have got it wrong, but I believe what he was saying was that 
> much of his system was working. The part that doesn’t work is when (e.g.) the 
> Font Manager updates the dictionary directly, by which I mean it changes 
> values in the dictionary, but does not replace the entire dictionary in the 
> model object (it can’t do that, it doesn’t know where to find the model 
> object, or what the property name of the dictionary in the model object is).
> 
> In this kind of update, Graham is expecting a KVO notification “for the 
> dictionary”, in order to trigger keyPathsForValuesAffectingThingy. I’m saying 
> that can’t possibly happen.
> 
> 

I agree that if what he’s doing is changing values in the dictionary then he’s 
not going to get a change notification for the dictionary. I just read his 
message again and I can’t read it as saying anything else than the entire 
dictionary is being replaced, perhaps it’s just how I read it. I think we need 
some clarification here about what’s really getting changed. 
___

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

Re: KVO question

[Roland King]

> On 19 Nov 2015, at 08:15, Quincey Morris 
>  wrote:
> 
> On Nov 18, 2015, at 14:35 , Graham Cox  wrote:
>> 
>> it’s just that if other code changes the attributes dictionary (such as the 
>> Font Manager) then I need these split out properties to trigger their 
>> notifications so that the UI shows the change
> 
> I think I understand, finally. No, what you’re doing won’t work.
> 
> The problem is that if (say) the Font Manager has a pointer to your 
> NSMutableDictionary object, and mutates it — sets a new value for a key — 
> there *will* be a KVO notification** — I believe we know that the standard 
> NSMutableDictionary class issues KVO notifications for value changes, though 
> I’m not sure whether it’s documented — but it won’t be a notification for the 
> dictionary***, it will be a notification for the individual key.
> 

I didn’t read his original question as saying that however, that he was 
mutating an individual element of a mutable dictionary property. Grabbing what 
was written

> So what I want (expect?) is that is code sets -dictionaryOfThings directly, 
> an observer of ‘thingy’ will be triggered. Is that right?


which when you look at it doesn’t quite make sense, -dictionaryOfThings is a 
method so you can’t set it so I assumed it meant replacing the whole dictionary 
like so

myObject.dictionaryOfThings = newDictionaryOfNewThings;

or calling

[ myObject setDictionaryOfThings:newDictionaryOfNewThings ];

then the original dependent KVO code as-written should fire, for every property 
which has dictionaryOfThings as a dependent key. 

A bit of clarification about what was meant by ‘code setting 
-dictionaryOfThings directly’ might help. 


___

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

Re: KVO question

[Quincey Morris]

(sorry, posted the incomplete message by accident)

On Nov 18, 2015, at 16:29 , Roland King > 
wrote:
> 
> I didn’t read his original question as saying that

I could easily have got it wrong, but I believe what he was saying was that 
much of his system was working. The part that doesn’t work is when (e.g.) the 
Font Manager updates the dictionary directly, by which I mean it changes values 
in the dictionary, but does not replace the entire dictionary in the model 
object (it can’t do that, it doesn’t know where to find the model object, or 
what the property name of the dictionary in the model object is).

In this kind of update, Graham is expecting a KVO notification “for the 
dictionary”, in order to trigger keyPathsForValuesAffectingThingy. I’m saying 
that can’t possibly happen.


___

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

Re: KVO question

[Graham Cox]

Hi guys, thanks for your replies - sorry took a while to get back to this, was 
in a long meeting.


Anyway, Quincey, I’m not trying to get notified for mutations to the 
dictionary. The dictionary is being replaced as a single entity wholesale.


The way the font manager works is that for a given attribute change, it asks 
the first responder to send it the dictionary of attributes for the selected 
text. (-changeAttributes:) It then mutates a copy of that dictionary 
(-convertAttributes:) and returns the entire mutated copy. The text view then 
applies that as a single object to the selected text run.

In my case I’ve actually wrapped the text (attributed string) in another object 
that splits out specific text-related properties separately, which makes it 
much easier to bind these properties to particular bits of UI, for example 
changing the Font. That all works - if I set my -font property, internally it 
changes the font attribute in the -textAttributes property, I get notifications 
on both -font and -textAttributes. If I change the text selection, the 
attributes applying to that run trigger notifications for the font property in 
my UI. If some other object (e.g. Font Manager) changes the font using its 
normal mechanism, which updates the -textAttributes property directly, I need 
notifications to be triggered for the -font property. In fact, they are, 
because I have +keyPathsForValuesAffectingFont returning textAttributes.

However this was not working consistently for all properties. I was trying to 
boil it down to generalities hence my dictionaryOfThings and thingy 
terminology, just to clarify that my understanding of KVO was correct. Seems it 
was. So my problem must be something specific in my code because in fact this 
is working for nearly everything, just not all. So if my understanding of KVO 
is correct, I now know where to look for these few missing pieces.


—Graham






> On 19 Nov 2015, at 11:38 AM, Quincey Morris 
>  wrote:
> 
> (sorry, posted the incomplete message by accident)
> 
> On Nov 18, 2015, at 16:29 , Roland King  wrote:
>> 
>> I didn’t read his original question as saying that
> 
> I could easily have got it wrong, but I believe what he was saying was that 
> much of his system was working. The part that doesn’t work is when (e.g.) the 
> Font Manager updates the dictionary directly, by which I mean it changes 
> values in the dictionary, but does not replace the entire dictionary in the 
> model object (it can’t do that, it doesn’t know where to find the model 
> object, or what the property name of the dictionary in the model object is).
> 
> In this kind of update, Graham is expecting a KVO notification “for the 
> dictionary”, in order to trigger keyPathsForValuesAffectingThingy. I’m saying 
> that can’t possibly happen.
> 
> 


___

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

Re: KVO question

[Quincey Morris]

On Nov 18, 2015, at 14:35 , Graham Cox  wrote:
> 
> it’s just that if other code changes the attributes dictionary (such as the 
> Font Manager) then I need these split out properties to trigger their 
> notifications so that the UI shows the change

I think I understand, finally. No, what you’re doing won’t work.

The problem is that if (say) the Font Manager has a pointer to your 
NSMutableDictionary object, and mutates it — sets a new value for a key — there 
*will* be a KVO notification** — I believe we know that the standard 
NSMutableDictionary class issues KVO notifications for value changes, though 
I’m not sure whether it’s documented — but it won’t be a notification for the 
dictionary***, it will be a notification for the individual key.

This will have no effect (assuming I’m still on track) because nothing is 
observing the key path that’s getting the notification. Your UI observers are 
watching yourModel.thingy instead, and your keyPathsForValuesAffectingThingy 
doesn’t fire for the reason given above.

What will work (assuming I’m still on track) is to bind your UI elements to 
yourModel.dictionaryOfThings.thingy instead of yourModel.thingy. In that case, 
a Font Manager update to the dictionary will trigger an update that reaches the 
UI.

The hard part comes if you something is observing the dictionary itself (for 
example, to tell the text system to update when the dictionary changes 
externally). A UI element update will trigger a KVC notification on path 
yourModel.dictionaryOfThings.thingy, but *not* on path 
yourModel.dictionaryOfThings, so the dictionary observer won’t fire. But 
there’s nothing in your existing sample code to suggest that anything is 
observing the dictionary like this, except to trigger the model updates on the 
duplicate properties, which aren’t needed in the scheme I’m suggesting.

It’s a while since we’ve discussed KVO vs. NSMutableDictionary on this list, so 
I may be misremembering how this all works. (Ken can probably straighten that 
out.) Even if it doesn’t work this way, if you are in charge of creating the 
NSMutableDictionary initially, you could write a subclass and give it whatever 
KVO notification behavior you want. Otherwise, you might be able to achieve 
your goal by adding another set of observers to the dictionary keys themselves.


** Maybe that should be “would”, not “will”, since you have no observers of 
this. There are no notifications for regular properties unless something is 
observing them. I’m not sure whether NSMutableDictionary issues notifications 
unconditionally or knows what keys are being observed.

***There can’t be a notification for the dictionary itself, because the code 
that’s mutating it doesn’t know what key to use.
___

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

Re: KVO question

[Graham Cox]

> On 18 Nov 2015, at 6:43 PM, Quincey Morris 
>  wrote:
> 
> As a matter of principle, I always think using a dictionary as an API to 
> properties is a terrible idea. You’re much better off defining an object that 
> actually has the properties, even if there are a lot of them. That would 
> solve your difficulty here, since you wouldn’t need two ways of getting to 
> the properties. Also, you’d avoid the danger inherent in exposing your 
> mutable backing store (the NSMutableDictionary) to the outside world, always 
> a prescription for trouble.
> 


I completely agree, but in this case the dictionary in question is the 
attributes of NSAttributedString (in a NSTextView), so I don’t have the choice. 
I have split out numerous individual properties from this so that they are easy 
to bind to specific UI, such as a menu for Font, a menu for font face, a text 
field for font size, etc, etc. But ultimately they have to change the 
attributes dictionary. That all works, it’s just that if other code changes the 
attributes dictionary (such as the Font Manager) then I need these split out 
properties to trigger their notifications so that the UI shows the change. The 
dictionary is being changed in a KVO compliant way, because the entire 
dictionary is updated and replaced as a whole - the settings within the 
dictionary are not mutated individually.

—Graham





___

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

Re: KVO question

[Daniel Stenmark]

It seems like it *should* work.  Are you sure you don’t have a typo in your 
addObserver: method?  Considering that you’re using the dictionary’s property 
setter, keyPathsForValuesAffecting shouldn’t even be necessary.  When I 
apply KVO, I try to mitigate the potential unsafely of key paths strings by 
using NSStringFromSelector() whenever possible.

[self.foo addObserver:self forKeyPath:NSStringFromSelector(@selector(bar)) 
options:NSKeyValueObservingOptionNew context:NULL];

Dan


On Nov 17, 2015, at 5:18 PM, Graham Cox 
> wrote:

I’m using KVO to observe a bunch of properties.

Most of these properties are split out into simple things that set a single 
value, but internal to my object, some end up setting a common dictionary of 
attributes, which is also a property.

I KVO observe both the simple properties and the common dictionary property. 
Mostly this is working, but when code directly sets the dictionary property, 
the other properties don’t trigger their observers, even though I’m 
implementing the +keyPathsForValuesAffecting, which I believe should 
cause the additional triggering. Have I understood that right?

Here’s the kind of code I have:


@property (retain) id thingy;
@property (retain) NSDicitonary* dictionaryOfThings;

@implementation

- (void)   setThingy:(is thing
{
NSMutableDictionary* temp = [self.dictionaryOfThings mutableCopy];
[temp setObject:thing forKey:kThingKey];
self.dictionaryOfThings = temp;
}

- (id) thingy
{
return [self.dictionaryOfThings objectForKey:kThingKey];
}


+ (NSSet*)  keyPathsForValuesAffectingThingy
{
return [NSSet setWithObject:@“dictionaryOfThings”];
}


So what I want (expect?) is that is code sets -dictionaryOfThings directly, an 
observer of ‘thingy’ will be triggered. Is that right?


—Graham



___

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/dstenmark%40opentable.com

This email sent to dstenm...@opentable.com

___

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

Re: KVO question

[Quincey Morris]

On Nov 17, 2015, at 17:18 , Graham Cox  wrote:
> 
> Mostly this is working, but when code directly sets the dictionary property, 
> the other properties don’t trigger their observers, even though I’m 
> implementing the +keyPathsForValuesAffecting, which I believe 
> should cause the additional triggering. Have I understood that right?

It’s not clear. I can’t think of a compelling reason why the other observers 
shouldn’t trigger, but you are doing something a bit weird.

I wonder, also, if you’re always setting the ‘dictionaryOfThings’ property 
KVO-compliantly? In particular, is the instance variable perhaps changed 
initially from nil to an empty dictionary after there are already observers on 
the dictionary path?

As a matter of principle, I always think using a dictionary as an API to 
properties is a terrible idea. You’re much better off defining an object that 
actually has the properties, even if there are a lot of them. That would solve 
your difficulty here, since you wouldn’t need two ways of getting to the 
properties. Also, you’d avoid the danger inherent in exposing your mutable 
backing store (the NSMutableDictionary) to the outside world, always a 
prescription for trouble.

FWIW.


___

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

Re: KVO detection of changes to selection in NSOpenPanel

[Kyle Sluder]

On Mon, Jul 20, 2015, at 11:13 AM, Jonathan Taylor wrote:
 This does make me wonder if I should perhaps not be surprised that my use
 of keyPathsAffectingValueForKey is not going well, although nothing in
 that statement seems to specifically preclude what I am doing from
 working on 10.8. Does anyone know if there’s any hope of my KVO approach
 working?

No. If a property is not explicitly documented to be KVO-compliant, you
must assume that it isn't.

The alternative seems to be to implement a delegate method for
 panelSelectionDidChange. Would that be the sensible way to deal with
 this, or is there a third and better way I should be using?

It seems pretty straightforward to just implement the delegate method
regardless of OS version.

--Kyle Sluder

___

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

Re: KVO query

[Jonathan Mitchell]

On 13 Aug 2014, at 23:41, Quincey Morris quinceymor...@rivergatesoftware.com 
wrote:

 On Aug 13, 2014, at 14:53 , Jonathan Mitchell jonat...@mugginsoft.com wrote:
 
 At one point i need to invoke a manual KVO notification like so:
 
 [submission willChangeValueForKey:@“status”];
 [submission didChangeValueForKey:@“status”];
 
 This raises like so:
 
 Terminating app due to uncaught exception 
 'NSInternalInconsistencyException', reason: 'Cannot update for observer 
 NSKeyValueObservance 0x608000ac21b0 for the key path status.name from 
 Submission 0x6080003aa800, most likely because the value for the key 
 status has changed without an appropriate KVO notification being sent. 
 Check the KVO-compliance of the Submission class.’
 
 This is one of those infuriating errors that is hard to make sense of. Try 
 thinking about it literally.
 
 Because you’re observing the “status.name” path from ‘submission’, the 
 observer is *also* observing the “name” path from ‘submission.status’**. In 
 your scenario, the originally observed ‘status’ instance (call it X) is no 
 longer the current ‘status’ instance at willChange time (it’s now Y, say), 
 and in general it might not be the same as that at didChange time (Z, say). 
 Even if Y == Z, there’s been a non-KVO-compliant change in ‘status’ prior to 
 the notification being sent.
 
 Now, we do this quite often, without problems, but I’d suggest that’s only in 
 cases where the “temporarily non KVO compliant” change is for the *last* key 
 of the path — in which case the last object isn’t being observed, just 
 because it’s the last key.

This is where I am getting caught out. As you say it works fine for the last 
key of the path. It does for me too.

I am effectively propagating a C# PropertyChanged event. This approach by 
itself will never be KVO compliant and will fail when mutating non last 
components in an observed key path.
 
 So, in the case of a non-KVO-compliant change to the value of a non-terminal 
 key path object, the non-KVO-compliance may not be tolerated by the 
 frameworks. Hence this error message.
 
 What I suggest you try is to make two properties: “currentStatus” and 
 “observableStatus”. The second of these would be updated KVO compliantly 
 (i.e. via its setter) when you know that the first has changed and the change 
 should be propagated (i.e. in the places where you now trigger the 
 willChange/didChange notification manually). Code in the ‘submission’ class 
 can use ‘self.currentStatus’ to get or set the most recent status object; 
 observers would observe “observableStatus”, of course.
Using a proxy property sounds like it might be doable.

Thanks

Jonathan
___

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

Re: KVO query

[Jonathan Mitchell]

On 13 Aug 2014, at 23:40, Ken Thomases k...@codeweavers.com wrote:

 
 You have to issue the -willChange… _before_ the property has changed.  That's 
 because that's KVO's only opportunity to get the value that's about to become 
 old and remove its observations for the properties of that old object.
 
 So, that pattern of issuing -willChange… followed immediately by -didChange… 
 with nothing actually changing in between is a sure sign of a problem.
 
 The solution is annoying but relatively simple.  You need to hold a strong 
 reference to the old object in a property of your own.  So, you need a 
 property status that is _not_ just a pass-through to some other API.  It 
 needs to be backed by an instance variable (e.g. _status) that is a strong 
 reference to the object.  Then, when you receive the notification from the 
 underlying API that something has changed, you fetch the new object from that 
 API and assign it to self.status.  That assignment is KVO-compliant.  You 
 can/should then eliminate your manual -will/didChange… invocations.
 

That all makes sense.

I am effectively just propagating the C# PropertyChanged event. This is 
fundamentally not KVO compliant.
C# also provides a PropertyChanging event, though it is not so commonly 
implemented.

For managed event changes to be KVO compliant in managed code I will have to 
ensure that the managed layer events are sent in a may that is KVO compliant 
when they emerge in unmanaged code.

Thanks

Jonathan


___

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

Re: KVO query

[Lee Ann Rucker]

Have you implemented +automaticallyNotifiesObserversForKey: and returned NO for 
“status” ?

On Aug 13, 2014, at 2:53 PM, Jonathan Mitchell jonat...@mugginsoft.com wrote:

 I have a key path like so which is observed:
 
 submission.status.name
 
 At one point i need to invoke a manual KVO notification like so:
 
 [submission willChangeValueForKey:@“status”];
 [submission didChangeValueForKey:@“status”];
 
 This raises like so:
 
 Terminating app due to uncaught exception 'NSInternalInconsistencyException', 
 reason: 'Cannot update for observer NSKeyValueObservance 0x608000ac21b0 for 
 the key path status.name from Submission 0x6080003aa800, most likely 
 because the value for the key status has changed without an appropriate KVO 
 notification being sent. Check the KVO-compliance of the Submission class.’
 
 I am using manual KVO because my submission object is a wrapper around a Mono 
 managed class.
 I receive a callback that the managed status object has changed and want to 
 propagate that via KVO.
 The true situation is generic : i receive a callback that a managed property 
 P has changed and want to raise manual KVO notifications in a compliant 
 manner.
 
 Is there a way for me to programatically determine what sequence of manual  
 KVO notifications  I will require to maintain KVO compliance?
 I imagine that the framework code uses - observationInfo to achieve this but 
 that is opaque to client code.
 I am trying to avoid having lots of explicit 
 +keyPathsForValuesAffectingValueForKey: methods.
 
 Thanks
 
 Jonathan


___

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

Re: KVO query

[Ken Thomases]

On Aug 13, 2014, at 4:53 PM, Jonathan Mitchell jonat...@mugginsoft.com wrote:

 I have a key path like so which is observed:
 
 submission.status.name
 
 At one point i need to invoke a manual KVO notification like so:
 
 [submission willChangeValueForKey:@“status”];
 [submission didChangeValueForKey:@“status”];
 
 This raises like so:
 
 Terminating app due to uncaught exception 'NSInternalInconsistencyException', 
 reason: 'Cannot update for observer NSKeyValueObservance 0x608000ac21b0 for 
 the key path status.name from Submission 0x6080003aa800, most likely 
 because the value for the key status has changed without an appropriate KVO 
 notification being sent. Check the KVO-compliance of the Submission class.’
 
 I am using manual KVO because my submission object is a wrapper around a Mono 
 managed class.
 I receive a callback that the managed status object has changed and want to 
 propagate that via KVO.
 The true situation is generic : i receive a callback that a managed property 
 P has changed and want to raise manual KVO notifications in a compliant 
 manner.
 
 Is there a way for me to programatically determine what sequence of manual  
 KVO notifications  I will require to maintain KVO compliance?

You have to issue the -willChange… _before_ the property has changed.  That's 
because that's KVO's only opportunity to get the value that's about to become 
old and remove its observations for the properties of that old object.

So, that pattern of issuing -willChange… followed immediately by -didChange… 
with nothing actually changing in between is a sure sign of a problem.

The solution is annoying but relatively simple.  You need to hold a strong 
reference to the old object in a property of your own.  So, you need a property 
status that is _not_ just a pass-through to some other API.  It needs to be 
backed by an instance variable (e.g. _status) that is a strong reference to the 
object.  Then, when you receive the notification from the underlying API that 
something has changed, you fetch the new object from that API and assign it to 
self.status.  That assignment is KVO-compliant.  You can/should then eliminate 
your manual -will/didChange… invocations.

Regards,
Ken


___

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

Re: KVO query

[Quincey Morris]

On Aug 13, 2014, at 14:53 , Jonathan Mitchell jonat...@mugginsoft.com wrote:

 At one point i need to invoke a manual KVO notification like so:
 
 [submission willChangeValueForKey:@“status”];
 [submission didChangeValueForKey:@“status”];
 
 This raises like so:
 
 Terminating app due to uncaught exception 'NSInternalInconsistencyException', 
 reason: 'Cannot update for observer NSKeyValueObservance 0x608000ac21b0 for 
 the key path status.name from Submission 0x6080003aa800, most likely 
 because the value for the key status has changed without an appropriate KVO 
 notification being sent. Check the KVO-compliance of the Submission class.’

This is one of those infuriating errors that is hard to make sense of. Try 
thinking about it literally.

Because you’re observing the “status.name” path from ‘submission’, the observer 
is *also* observing the “name” path from ‘submission.status’**. In your 
scenario, the originally observed ‘status’ instance (call it X) is no longer 
the current ‘status’ instance at willChange time (it’s now Y, say), and in 
general it might not be the same as that at didChange time (Z, say). Even if Y 
== Z, there’s been a non-KVO-compliant change in ‘status’ prior to the 
notification being sent.

Now, we do this quite often, without problems, but I’d suggest that’s only in 
cases where the “temporarily non KVO compliant” change is for the *last* key of 
the path — in which case the last object isn’t being observed, just because 
it’s the last key.

So, in the case of a non-KVO-compliant change to the value of a non-terminal 
key path object, the non-KVO-compliance may not be tolerated by the frameworks. 
Hence this error message.

What I suggest you try is to make two properties: “currentStatus” and 
“observableStatus”. The second of these would be updated KVO compliantly (i.e. 
via its setter) when you know that the first has changed and the change should 
be propagated (i.e. in the places where you now trigger the 
willChange/didChange notification manually). Code in the ‘submission’ class can 
use ‘self.currentStatus’ to get or set the most recent status object; observers 
would observe “observableStatus”, of course.



** Because there’re “really” no such thing as a key path observation. It’s 
“really” a chain of object/key observations.

___

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

Re: KVO - receptionist design pattern

[Quincey Morris]

On Dec 1, 2013, at 07:26 , Kevin Meaney k...@yvs.eu.com wrote:

 This property is mostly changed on a queue that is not the main queue (gcd 
 queues, not NSOperation queues). Everything works as I would like but I'm 
 concerned that it is only working out of luck rather than proper design.

You didn’t actually state the nature of your concern. You’re worried 
specifically about the problem of triggering a UI update on a background 
thread? If so, then, yes, you’ve been lucky if it worked.

 Has something changed in Mavericks so that doing this is no longer a problem, 
 or do I need to fix.

Nothing’s changed in Mavericks AFAIK, so you should fix your code.

 Because this is a simple case (I know when I'm not on the main thread) I can 
 easily fix with just wrapping the modification of the property like so:
 
 __weak AppDelegate *weakSelf = self;
 dispatch_async(dispatch_get_main_queue(), ^
 {
  AppDelegate *strongSelf = weakSelf;
  if (strongSelf)
strongSelf.isAgentRunning = isRunning ? @Yes : @No;
 });
 
 But of course this is fine in my simple case, and since this is all I need 
 I'll go with this.

Yes, but why are you taking the trouble to “avoid” a reference cycle when none 
can be formed? What’s wrong with the simple version?

dispatch_async(dispatch_get_main_queue(), ^
{
self.isAgentRunning = isRunning ? @Yes : @No;
});

Certainly the block captures ‘self’ in this case, but nothing other than the 
queue captures the block.

 But what I suppose I'm asking is, are others using the receptionist design 
 pattern, is it the way to go for a robust solution to this problem?

It’s no robuster than the “simple” solution. It’s useful when the object 
modifying the property doesn’t or can’t know whether it’s a background thread — 
for example, when it’s in a 3rd party library you don’t control. But in your 
own code, you can always use [NSThread isMainThread] to decide whether to 
update the property synchronously or asynchronously.

___

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

Re: KVO - receptionist design pattern

[Kevin Meaney]

On 1 Dec 2013, at 18:27, Quincey Morris quinceymor...@rivergatesoftware.com 
wrote:

 On Dec 1, 2013, at 07:26 , Kevin Meaney k...@yvs.eu.com wrote:
 
 This property is mostly changed on a queue that is not the main queue (gcd 
 queues, not NSOperation queues). Everything works as I would like but I'm 
 concerned that it is only working out of luck rather than proper design.
 
 You didn’t actually state the nature of your concern. You’re worried 
 specifically about the problem of triggering a UI update on a background 
 thread? If so, then, yes, you’ve been lucky if it worked.

My concern was that would I be doing a pointless fix, because I missed the note 
that in some recent OS upgrade someone at Apple decided that when we bind 
properties in the interface editor that the UI observing of that property 
should only happen on the main thread. As you pointed out, that is not the case.

 __weak AppDelegate *weakSelf = self;
 dispatch_async(dispatch_get_main_queue(), ^
 {
  AppDelegate *strongSelf = weakSelf;
  if (strongSelf)
strongSelf.isAgentRunning = isRunning ? @Yes : @No;
 });
 
 But of course this is fine in my simple case, and since this is all I need 
 I'll go with this.
 
 Yes, but why are you taking the trouble to “avoid” a reference cycle when 
 none can be formed? What’s wrong with the simple version?

Your exactly right. Thanks

 It’s no robuster than the “simple” solution. It’s useful when the object 
 modifying the property doesn’t or can’t know whether it’s a background thread 
 — for example, when it’s in a 3rd party library you don’t control. But in 
 your own code, you can always use [NSThread isMainThread] to decide whether 
 to update the property synchronously or asynchronously.

I meant more robust in the sense that if you use the Receptionist design 
pattern, you don't in the future have to think about whether the assignment 
your making to that property is being done on the main thread or not. An 
approach I usually prefer and I think is more robust. Perhaps we have different 
definitions of robust in this case.

Kevin


___

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

Re: KVO on a key path with nil intermediate properties

[Sean McBride]

On Wed, 26 Jun 2013 18:51:34 -0700, Rick Mann said:

Can one set up KVO on a property of a property if the intermediate one
is nil, and then get notified when either changes? In practice, it seems
not, as I don't get notified for either the intermediate property or the
leaf property.

As you discovered 5 minutes after posting :), this works as expected.  I do it 
all the time.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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

Re: KVO on a key path with nil intermediate properties

[Rick Mann]

Hmm, after all that, it seems that it's actually behaving the way I would 
expect. Sorry for the noise.

On Jun 26, 2013, at 18:51 , Rick Mann rm...@latencyzero.com wrote:

 I've looked through the docs and googled, but I can't find an answer to this 
 question, so if it's obvious, forgive me.
 
 Can one set up KVO on a property of a property if the intermediate one is 
 nil, and then get notified when either changes? In practice, it seems not, as 
 I don't get notified for either the intermediate property or the leaf 
 property. In that case, it seems that I have to observer the intermediate 
 properties individually, and then when those change, ignore and observe their 
 sub properties.
 
 Let's say I have three classes, A, B, and C. A has a b* b property, and B and 
 C have properties foo and bar, respectively:
 
@interface B : NSObject
 
@property (strong) NString* bar;
 
@end
 
 ---
 
@interface A : NSObject
 
@property (strong) B*   foo;
 
@end
 
 ---
 
 
 Can I do:
 
@implementation SomeClass
 
- (void)
observeValueForKeyPath: (NSString*) inKeyPath
ofObject: (id) inObject
change: (NSDictionary*) inChange
context: (void*) inContext
{
if ([inKeyPath isEqualToString: @foo.bar])
{
// Yay!
//  Notified when a.foo changes
//  Notified when a.foo.bar changes
}
else
{
[super observeValueForKeyPath: inKeyPath ofObject: inObject 
 change: inChange context: inContext];
}
}
 
- (void)
test
{
A* a = [[A alloc] init];
 
[a addObserver: self
forKeyPath: @foo.bar
options: NSKeyValueObservingOptionInitial | 
 NSKeyValueObservingOptionNew
context: NULL];
 
...
 
 And be notified in these two instances:
 
...
 
B* b = [[B alloc] init];
a.foo = b;  //  Notified because foo changed from nil to something
 
b.bar = @something;   //  Notified because bar changed
}
 
 
 
 
 -- 
 Rick
 
 
 
 
 ___
 
 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/rmann%40latencyzero.com
 
 This email sent to rm...@latencyzero.com


-- 
Rick




___

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

Re: KVO, which thread?

[Robert Monaghan]

Hi, Todd,

Set a breakpoint and see which thread it stops on.

(It is probably not the main thread. But you will find out for certain with the 
breakpoint.)

Bob

Sent from my iPhone

On Feb 4, 2013, at 22:44, Todd Heberlein todd_heberl...@mac.com wrote:

 I have an NSInvocationOperation, anOp, and register to observe when its 
 isFinished variable is set
 
 [anOp addObserver:self forKeyPath:@isFinished 
 options:NSKeyValueObservingOptionNew context:NULL];
 
 When my operation is done, isFinished is set, and thus my method 
 -observeValueForKeyPath:ofObject:change:context: is called, which thread is 
 it being called on? The main thread, or the thread created to process the 
 NSInvocationOperation?
 
 Thanks,
 
 Todd
 
 ___
 
 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/bob%40gluetools.com
 
 This email sent to b...@gluetools.com

___

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

Re: KVO, which thread?

[Todd Heberlein]

On Feb 4, 2013, at 1:54 PM, Robert Monaghan b...@gluetools.com wrote:

 Set a breakpoint and see which thread it stops on.
 
 (It is probably not the main thread. But you will find out for certain with 
 the breakpoint.)

Brilliantly simple!  Thanks. And your hunch is correct. It was not thread #1 
(it was #4 in this instance).

Todd

___

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

Re: KVO, which thread?

[Mike Abdullah]

On 4 Feb 2013, at 21:44, Todd Heberlein todd_heberl...@mac.com wrote:

 I have an NSInvocationOperation, anOp, and register to observe when its 
 isFinished variable is set
 
 [anOp addObserver:self forKeyPath:@isFinished 
 options:NSKeyValueObservingOptionNew context:NULL];
 
 When my operation is done, isFinished is set, and thus my method 
 -observeValueForKeyPath:ofObject:change:context: is called, which thread is 
 it being called on? The main thread, or the thread created to process the 
 NSInvocationOperation?

Unless something in NSOperation goes out of its way to deliver the notification 
on a particular thread, the answer is: whichever thread caused the KVO 
notification to be fired.


___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Richard Somers]

On Sep 11, 2012, at 10:06 AM, Motti Shneor su...@bezeqint.net wrote:

 OK. Could you spare some pseudo-code for this? Or some link to a known 
 code-sample? or maybe some 10 highlight lines from your own utilities?
 
 Documentation on method swizzling isn't that easy to use. In my case, all I 
 need to do is to swizzle? (like override) the addObserver of my observed 
 object, and record the high-level observation info (observer, options, 
 context, etc.) in some static container, so I can later question the observed 
 object about its observer. 
 
 But how do I do that on my NSManagedObject sublcass?

Sorry about the delayed response. I have been buried in work. I switched to 
10.8 Mountain Lion and I am still adjusting to the revised Mail applicaiton. 
You could do swizzling like this.

#import JRSwizzle.h

@implementation NSManagedObject (MySpecialCategory)

// Do the swizzling
+ (void)load
{
@autoreleasepool // NSAssert requires an autorelease pool
{
NSError *error = nil;
[[NSObject class] jr_swizzleMethod:@selector(method)
withMethod:@selector(my_swizzled_method)
 error:error];
NSAssert(error == nil, @%@, error);
}
}

// Framework method
// - (void)method
// {
//  ...
// }

// Swizzled method
- (void)my_swizzled_method
{
// do your thing

// call original implementation
[self my_swizzled_method];
}

@end

Note that the NSManagedObject documentation indicates As with any class, you 
are strongly discouraged from overriding the key-value observing methods. I 
view swizzling like this: You are at your wits end, you have examined all other 
options, you want to use Apple's frameworks but you simply can figure out any 
other way. So you try swizzling.

--Richard Somers


___

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

Re: KVO change dict not reflecting edits in UI

[Kyle Sluder]

Your pattern here seems backwards. Undo managers typically don't observe 
objects themselves. Model objects register reverse actions with the undo 
manager when their properties change. In your case, you might consider 
overriding -willChangeValueForKey: to register the undo action to revert the 
property to its old value.

Also, don't design for a singleton undo manager. Having multiple undo managers 
is a very useful case.

Your -registerObserver: method is kind of odd, but I understand the motivation: 
you want to keep the set of observable properties in one place. If you follow 
the above advice of making your model objects responsible for registering 
undos, then perhaps you can avoid exposing this method.

--Kyle Sluder
(Sent from the road)

On Sep 22, 2012, at 1:12 PM, Erik Stainsby erik.stain...@roaringsky.ca wrote:

 Hello again list,
 
 I have a custom object class RSPerson with a handful of string properties. I 
 have registered a singleton undoManager to observe changes, but the change 
 dict is always coming up symmetrical. 
 
 Edits made to the properties through UI do not appear in the change dict.
 However setting the stringValue from the UI on the custom objects' properties 
 does trigger the observer method (?!)
 
 Some code. The observer is set on each person as the person is populated. 
 
 RSPerson:
 
 #import Foundation/Foundation.h
 @interface RSPerson : NSObject
 
 @property (strong) IBOutlet NSString * firstName;
 @property (strong) IBOutlet NSString * lastName;
 @property (strong) IBOutlet NSString * organization;
 
 @property (strong) IBOutlet NSUndoManager * observer;
 
 - (void) registerObserver:(id)observer;
 
 @end
 
 @implementation RSPerson
 
 - (id) init {
self = [super init];
if(self) {
 
}
return self;
 }
 
 - (void) registerObserver:(id)observer {
self.observer = observer;
[self addObserver:observer forKeyPath:@firstName  
 options:(NSKeyValueObservingOptionNew|NSKeyValueObservingOptionOld) 
 context:NULL];
[self addObserver:observer forKeyPath:@lastName   
 options:(NSKeyValueObservingOptionNew|NSKeyValueObservingOptionOld) 
 context:NULL];
[self addObserver:observer forKeyPath:@organization   
 options:(NSKeyValueObservingOptionNew|NSKeyValueObservingOptionOld) 
 context:NULL];
 }
 
 - (void) dealloc {
[self removeObserver:self.observer forKeyPath:@firstName];
[self removeObserver:self.observer forKeyPath:@lastName];
[self removeObserver:self.observer forKeyPath:@organization];
self.observer = nil;
 }
 
 @end
 
 
 
 RSUndoManager:
 
 #import Foundation/Foundation.h
 @interface RSUndoManager : NSUndoManager
 
 + (RSUndoManager *) sharedInstance;
 + (BOOL) sharedInstanceExists;
 
 - (void) observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object 
 change:(NSDictionary *)change context:(void *)context;
 
 @end
 
 @implementation RSUndoManager
 
 static RSUndoManager * instance = nil;
 
 + (RSUndoManager *) sharedInstance {
if(!instance ) {
instance = [[[self class] alloc] init];
}
return instance;
 }
 
 + (BOOL) sharedInstanceExists {
return (nil != instance);
 }
 
 - (id) init {
if(![[self class] sharedInstanceExists])
{
self = [super init];
if(self) {
}
return self;
}
return instance;
 }
 
 - (void) observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object 
 change:(NSDictionary *)change context:(void *)context
 {
NSLog(@ [%04d] %s %@: %@,__LINE__,__PRETTY_FUNCTION__, keyPath,[change 
 description]);
 
if([keyPath isEqualToString:@organization])
{
NSString * newVal = [change valueForKey:NSKeyValueChangeNewKey];
NSString * oldVal = [change valueForKey:NSKeyValueChangeOldKey];
if(newVal != oldVal) {
NSLog(@ [%04d] %s %@: %@: %@,__LINE__,__PRETTY_FUNCTION__, @ 
 not equal,oldVal,newVal);
}
else {
NSLog(@ [%04d] %s %@: %@: %@,__LINE__,__PRETTY_FUNCTION__, @ is 
 equal,oldVal,newVal);
}
}
 }
 
 @end
 
 
 The case illustrated here ought to be showing me distinct values when I enter 
 a value into my UI in the organization field. No such luck. 
 
 Any suggestions?
 
 
 
 Erik Stainsby
 erik.stain...@roaringsky.ca

___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Motti Shneor]

On 10 בספט 2012, at 20:22, Richard Somers wrote:

 On Sep 10, 2012, at 5:59 AM, Motti Shneor wrote:
 
 Although I don't need such heavy-weapons, and I don't at all deal with 
 programmatic bindings here, I'd still like (if possible) to learn some more 
 about the implementation of your internal tools. I didn't yet have a chance 
 to work with swizzling, and maybe its time I started.
 
 My case is not of complexity, but of performance. If I simply observe all 
 the time, and then filter what I need, penalty would be too much. I get huge 
 amount of observation-calls (every refresh of my core-data context) and I 
 need to inspect lots
 
 Method swizzling lets your replacement method make use of the original 
 method, almost like subclassing. In my case it let me add a form of bindings 
 introspection. For example, what objects currently have active bindings and 
 what are those bindings. I have found that the tools available for debugging 
 bindings to be almost non-existant. (None of the malloc diagnostics tools 
 help and for some reason adding -NSBindingDebugLogLevel 1 has never helped.)
 
 Given that bindings are just a relatively thin veneer on Key Value Observing 
 perhaps there is some similarity here.
 
 One of the problems I faced was that when an edit was underway certain 
 objects with active bindings would cause an avalanche of KVO notifications 
 resulting in a substantial performance penalty. One of the things I did to 
 help alleviate the situation was to programmatically remove and recreate the 
 binding for objects that did not directly participate in the edit.
 
 I guess this does seem like a lot of work but then again most people would 
 likely say that writing glue code is a lot of work.
 
 --Richard
 


OK. Could you spare some pseudo-code for this? Or some link to a known 
code-sample? or maybe some 10 highlight lines from your own utilities?

Documentation on method swizzling isn't that easy to use. In my case, all I 
need to do is to swizzle? (like override) the addObserver of my observed 
object, and record the high-level observation info (observer, options, context, 
etc.) in some static container, so I can later question the observed object 
about its observer. 

But how do I do that on my NSManagedObject sublcass?

Thanks,
-- Motti



___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Motti Shneor]

Thanks everyone. You are ALL right in your comments, and still my problem 
persists.

In reality, I have at least 6 external triggers or state-changes that 
determine (in a quite complicated way) whether or not I should observe that 
attribute.

The (rather wise!) suggestion to start my key-path at self, and so avoid the 
need to watch for representedObject changes could cure one of the 6. Still I 
have the other 5...

My question is general. Supposedly I could NOT start observing once, and stop 
it once. Reasons:
1. There are many instances of that NSViewController
2. This observation is quite frequent in time (could reach 100 times a second)
3. The code to filter-out unwanted value-changes is CPU intensive. (Accounting 
for 5 orthogonal conditions, upon which I should actually do something with the 
attribute change) 

So - I'd rather REMOVE the observation when I don't need it.

Currently, I have a BOOL ivar that I update whenever I start/stop the 
observation, and so I can avoid double-observations or exceptions trying to 
remove non-existent observation.

I ask about A GENERIC way to do this. I want to know my observation state 
programmatically. If that is impossible, or contrary to KVO design, I'll keep 
my current (rather ugly) code



On 10 בספט 2012, at 06:12, Lee Ann Rucker wrote:

 Yes, that approach is *so* much safer. When we switched over to doing it that 
 way so many dealloc called while object was being observed problems went 
 away.
 
 - Original Message -
 From: Quincey Morris quinceymor...@rivergatesoftware.com
 To: Motti Shneor su...@bezeqint.net
 Cc: Cocoa-Dev List Cocoa-dev@lists.apple.com
 Sent: Sunday, September 9, 2012 4:26:27 PM
 Subject: Re: KVO Question: How to programmatically determine if one object is 
 observing another on a keyPath and context?
 
 On Sep 9, 2012, at 13:50 , Motti Shneor su...@bezeqint.net wrote:
 
 On 9 בספט 2012, at 22:04, Ken Thomases wrote:
 
 Why is that a however?  What's the problem?  Since the representedObject 
 is KVO-compliant, all observations _through_ that property will 
 automatically follow it as it changes.
 
 Nope. When representedObject becomes nil, I DO NOT WANT to observe anything, 
 and I need to remove the observance from the previous representedObject, 
 BEFORE it is set to nil on my NSViewController.
 
 I think, by using the word through, Ken is suggesting you do this:
 
   [self addObserver:self forKeyPath:@representedObject.incomingNotes 
 ...];
 
 rather than this:
 
   [self.representedObject addObserver:self forKeyPath:@incomingNotes 
 ...];
 
 ___
 
 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/lrucker%40vmware.com
 
 This email sent to lruc...@vmware.com

Motti Shneor
e-mail: motti.shn...@gmail.com
phone: +972-8-9267730
mobile: +972-54-3136621

Ceterum censeo Microsoftinem delendam esse



___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Mike Abdullah]

On 10 Sep 2012, at 11:40, Motti Shneor su...@bezeqint.net wrote:

 Thanks everyone. You are ALL right in your comments, and still my problem 
 persists.
 
 In reality, I have at least 6 external triggers or state-changes that 
 determine (in a quite complicated way) whether or not I should observe that 
 attribute.
 
 The (rather wise!) suggestion to start my key-path at self, and so avoid the 
 need to watch for representedObject changes could cure one of the 6. Still I 
 have the other 5...
 
 My question is general. Supposedly I could NOT start observing once, and stop 
 it once. Reasons:
 1. There are many instances of that NSViewController
 2. This observation is quite frequent in time (could reach 100 times a second)
 3. The code to filter-out unwanted value-changes is CPU intensive. 
 (Accounting for 5 orthogonal conditions, upon which I should actually do 
 something with the attribute change) 
 
 So - I'd rather REMOVE the observation when I don't need it.

How much measurement have you done on this? In my experience, often the act of 
setting up or tearing down an observation is more time-consuming than leaving 
it running. Once the observation is in place, it's a fairly passive system.


___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[James Montgomerie]

On 10 Sep 2012, at 11:40, Motti Shneor su...@bezeqint.net wrote:
 My question is general. Supposedly I could NOT start observing once, and stop 
 it once. Reasons:
 1. There are many instances of that NSViewController
 2. This observation is quite frequent in time (could reach 100 times a second)
 3. The code to filter-out unwanted value-changes is CPU intensive. 
 (Accounting for 5 orthogonal conditions, upon which I should actually do 
 something with the attribute change) 

Does your view controller need to be aware of all these changes? 100s of 
changes a second is faster than your display can operate so, if this code is 
just to keep your UI up to date, there's potentially a lot of redundant work 
going on.

Is it possible that you could, instead of observing, do something simpler like 
poll for changes while whatever's causing them to happen is underway?  For 
example, could you use an NSTimer firing once every 30th or 15th of a second, 
calling a method that updates the UI?  This would avoid the overhead of 
processing all those 100s of changes per second in the view controller.

Jamie.


___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Motti Shneor]

Hello and thanks Richard. 

Although I don't need such heavy-weapons, and I don't at all deal with 
programmatic bindings here, I'd still like (if possible) to learn some more 
about the implementation of your internal tools. I didn't yet have a chance to 
work with swizzling, and maybe its time I started.

My case is not of complexity, but of performance. If I simply observe all the 
time, and then filter what I need, penalty would be too much. I get huge amount 
of observation-calls (every refresh of my core-data context) and I need to 
inspect lots 


On 9 בספט 2012, at 15:07, Richard Somers wrote:

 On Sep 9, 2012, at 3:32 AM, Motti Shneor wrote:
 
 - (NSUInteger)isObserver:(id)object on keyPath:(NSString *)keyPath 
 withContext:(void *)context]; // the returned number is the count of same 
 observances with 0 as not-observing).
 
 and something like 
 
 - (BOOL)removeObserver:(id)object;   // where I instruct the receiver to 
 remove object as an observer, on all key-paths and contexts. should return 
 YES if object was an observer, and was removed, NO otherwise.
 
 Any ideas?
 
 I recently did something similar only for bindings.
 
 @interface NSObject (MYBindings)
 + (NSString *)my_objectsWithActiveBindings; // for debugging
 + (NSUInteger)my_objectsWithActiveBindingsCount; // for debugging
 - (void)my_revmoveAllBindings;
 @end
 
 This was implemented by swizzling the NSObject implementation of 
 -bind:toObject:withKeyPath:options: and -unbind: at runtime using JRSwizzle 
 along with keeping binding information for each instance in a single static 
 mutable dictionary (associative storage pattern). The swizzled methods call 
 the NSObject implementation of -bind:... and -unbind: and also keep track of 
 the additional binding information needed.
 
 I am working on a project with a lot of programmatic bindings and I needed 
 some debugging aids and other routines to help with binding management. At 
 first I was hesitant to swizzle a framework method but I desperately needed 
 some help. So far it seems to be working well and the new routines helped 
 uncover a bug that I literally spent days trying to find with no success.
 
 --Richard
 

Motti Shneor
e-mail: motti.shn...@gmail.com
phone: +972-8-9267730
mobile: +972-54-3136621

Ceterum censeo Microsoftinem delendam esse



___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Mike Abdullah]

On 10 Sep 2012, at 12:59, Motti Shneor su...@bezeqint.net wrote:

 Hello and thanks Richard. 
 
 Although I don't need such heavy-weapons, and I don't at all deal with 
 programmatic bindings here, I'd still like (if possible) to learn some more 
 about the implementation of your internal tools. I didn't yet have a chance 
 to work with swizzling, and maybe its time I started.
 
 My case is not of complexity, but of performance. If I simply observe all the 
 time, and then filter what I need, penalty would be too much. I get huge 
 amount of observation-calls (every refresh of my core-data context) and I 
 need to inspect lots 

And you actually tried it, measured it, and determined observing all the time 
was too slow? Your wording makes it unclear. The KVO system has some slightly 
surprising performance characteristics in practice.


___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Motti Shneor]

There isn't much UI going on here. The representedObject is a CoreData managed 
object, updated frequently by remote server notifications. I'm observing a 
to-many relation somewhere down the attribute-path of the representedObject, 
trying to filter only those new/updated items of interest. 

Only very few of the changes actually cause UI updates in the viewController.

While observing those frequent changes, inspection of them in the model (which 
is constantly being updated), and filtering for the interesting ones is simply 
too CPU intensive. There are plenty of other parts of the program that need 
CPU. I'd like to avoid monitoring these changes when unnecessary. 

Again --- I already solved this, in a non-elegant way (BOOL ivar that records 
the observation-state). It would be nicer to do this in a general manner, and 
without a member. Preferably, rely on the internal KVO mechanism.

On 10 בספט 2012, at 14:23, James Montgomerie wrote:

 On 10 Sep 2012, at 11:40, Motti Shneor su...@bezeqint.net wrote:
 My question is general. Supposedly I could NOT start observing once, and 
 stop it once. Reasons:
 1. There are many instances of that NSViewController
 2. This observation is quite frequent in time (could reach 100 times a 
 second)
 3. The code to filter-out unwanted value-changes is CPU intensive. 
 (Accounting for 5 orthogonal conditions, upon which I should actually do 
 something with the attribute change) 
 
 Does your view controller need to be aware of all these changes? 100s of 
 changes a second is faster than your display can operate so, if this code is 
 just to keep your UI up to date, there's potentially a lot of redundant work 
 going on.
 
 Is it possible that you could, instead of observing, do something simpler 
 like poll for changes while whatever's causing them to happen is underway?  
 For example, could you use an NSTimer firing once every 30th or 15th of a 
 second, calling a method that updates the UI?  This would avoid the overhead 
 of processing all those 100s of changes per second in the view controller.
 
 Jamie.
 

Motti Shneor, Mac OS X Software Architect  Team Leader
Spectrum Reflections Ltd.




___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Richard Somers]

On Sep 10, 2012, at 5:59 AM, Motti Shneor wrote:

 Although I don't need such heavy-weapons, and I don't at all deal with 
 programmatic bindings here, I'd still like (if possible) to learn some more 
 about the implementation of your internal tools. I didn't yet have a chance 
 to work with swizzling, and maybe its time I started.
 
 My case is not of complexity, but of performance. If I simply observe all the 
 time, and then filter what I need, penalty would be too much. I get huge 
 amount of observation-calls (every refresh of my core-data context) and I 
 need to inspect lots

Method swizzling lets your replacement method make use of the original method, 
almost like subclassing. In my case it let me add a form of bindings 
introspection. For example, what objects currently have active bindings and 
what are those bindings. I have found that the tools available for debugging 
bindings to be almost non-existant. (None of the malloc diagnostics tools help 
and for some reason adding -NSBindingDebugLogLevel 1 has never helped.)

Given that bindings are just a relatively thin veneer on Key Value Observing 
perhaps there is some similarity here.

One of the problems I faced was that when an edit was underway certain objects 
with active bindings would cause an avalanche of KVO notifications resulting in 
a substantial performance penalty. One of the things I did to help alleviate 
the situation was to programmatically remove and recreate the binding for 
objects that did not directly participate in the edit.

I guess this does seem like a lot of work but then again most people would 
likely say that writing glue code is a lot of work.

--Richard


___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Richard Somers]

On Sep 9, 2012, at 3:32 AM, Motti Shneor wrote:

 - (NSUInteger)isObserver:(id)object on keyPath:(NSString *)keyPath 
 withContext:(void *)context]; // the returned number is the count of same 
 observances with 0 as not-observing).
 
 and something like 
 
 - (BOOL)removeObserver:(id)object;// where I instruct the receiver to 
 remove object as an observer, on all key-paths and contexts. should return 
 YES if object was an observer, and was removed, NO otherwise.
 
 Any ideas?

I recently did something similar only for bindings.

@interface NSObject (MYBindings)
+ (NSString *)my_objectsWithActiveBindings; // for debugging
+ (NSUInteger)my_objectsWithActiveBindingsCount; // for debugging
- (void)my_revmoveAllBindings;
@end

This was implemented by swizzling the NSObject implementation of 
-bind:toObject:withKeyPath:options: and -unbind: at runtime using JRSwizzle 
along with keeping binding information for each instance in a single static 
mutable dictionary (associative storage pattern). The swizzled methods call the 
NSObject implementation of -bind:... and -unbind: and also keep track of the 
additional binding information needed.

I am working on a project with a lot of programmatic bindings and I needed some 
debugging aids and other routines to help with binding management. At first I 
was hesitant to swizzle a framework method but I desperately needed some help. 
So far it seems to be working well and the new routines helped uncover a bug 
that I literally spent days trying to find with no success.

--Richard


___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Mike Abdullah]

On 9 Sep 2012, at 10:32, Motti Shneor su...@bezeqint.net wrote:

 Hi everyone. This seems a novice question, but I could not find any 
 high-level approach for that.
 
 Some details of my special need: I have an NSViewController subclass, that 
 should observe some attribute of its representedObject. 
 
 However, the representedObject may change to another, become nil  etc. 
 
 In addition, I have server-born triggers also affecting (stop/start) 
 observing that keyPath. 
 
 I'd like to code this in a local manner -- meaning, when a change occurs - 
 check if I'm already observing/not-observing the key-path, and either start, 
 stop or do nothing with the observation. In the -(void)dealloc of my 
 NSViewController, i'd also like to remove myself as an observer from whatever 
 objects I'm observing.
 
 I currently use state iVars that record the state of observation, but that's 
 ugly. I 'd like something like 
 
 
 - (NSUInteger)isObserver:(id)object on keyPath:(NSString *)keyPath 
 withContext:(void *)context]; // the returned number is the count of same 
 observances with 0 as not-observing).
 
 and something like 
 
 - (BOOL)removeObserver:(id)object;// where I instruct the receiver to 
 remove object as an observer, on all key-paths and contexts. should return 
 YES if object was an observer, and was removed, NO otherwise.
 
 Any ideas?

The KVO system does not support introspection. It is also not designed in such 
a way where a singly -removeObserver: method would be possible.

The intention is that observers just play by very simple rules. Add themselves 
at the start of observation, and remove themselves at the end. The system takes 
care of handling multiple observers neatly internally. By your description, it 
sound like in your view controller's init method you want to do this:

[self addObserver:self forKeyPath:@representedObject.someAttribute …

Tear it down again in -dealloc.


___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Ken Thomases]

On Sep 9, 2012, at 4:32 AM, Motti Shneor wrote:

 Hi everyone. This seems a novice question, but I could not find any 
 high-level approach for that.
 
 Some details of my special need: I have an NSViewController subclass, that 
 should observe some attribute of its representedObject. 
 
 However, the representedObject may change to another, become nil  etc. 

Why is that a however?  What's the problem?  Since the representedObject is 
KVO-compliant, all observations _through_ that property will automatically 
follow it as it changes.

Regards,
Ken


___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Motti Shneor]

On 9 בספט 2012, at 22:04, Ken Thomases wrote:

 On Sep 9, 2012, at 4:32 AM, Motti Shneor wrote:
 
 Hi everyone. This seems a novice question, but I could not find any 
 high-level approach for that.
 
 Some details of my special need: I have an NSViewController subclass, that 
 should observe some attribute of its representedObject. 
 
 However, the representedObject may change to another, become nil  etc. 
 
 Why is that a however?  What's the problem?  Since the representedObject is 
 KVO-compliant, all observations _through_ that property will automatically 
 follow it as it changes.
 

Nope. When representedObject becomes nil, I DO NOT WANT to observe anything, 
and I need to remove the observance from the previous representedObject, BEFORE 
it is set to nil on my NSViewController.

If I added myself as an observer to a specific object, in the following way: 

[self.representedObject addObserver:self forKeyPath:@incomingNotes 
options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld 
context:nil];

than it is MY responsibility to remove myself from that object, just before 
losing it (e.g. as my representedObject is set to nil).

Motti Shneor, Mac OS X Software Architect  Team Leader
Spectrum Reflections Ltd.



___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Fritz Anderson]

On 9 Sep 2012, at 3:50 PM, Motti Shneor su...@bezeqint.net wrote:

 Nope. When representedObject becomes nil, I DO NOT WANT to observe anything, 
 and I need to remove the observance from the previous representedObject, 
 BEFORE it is set to nil on my NSViewController.
 
 If I added myself as an observer to a specific object, in the following way: 
 
 [self.representedObject addObserver:self forKeyPath:@incomingNotes 
 options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld 
 context:nil];
 
 than it is MY responsibility to remove myself from that object, just before 
 losing it (e.g. as my representedObject is set to nil).

Perhaps I'm missing something. (I don't have the earlier part of the thread 
before me.) By I observe, you mean an observation on .representedObject, by 
an instance of the NSViewController subclass?

Can't you just override setRepresentedObject:, and adjust your observations 
accordingly? 

— F


___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Quincey Morris]

On Sep 9, 2012, at 13:50 , Motti Shneor su...@bezeqint.net wrote:

 On 9 בספט 2012, at 22:04, Ken Thomases wrote:
 
 Why is that a however?  What's the problem?  Since the representedObject 
 is KVO-compliant, all observations _through_ that property will 
 automatically follow it as it changes.
 
 Nope. When representedObject becomes nil, I DO NOT WANT to observe anything, 
 and I need to remove the observance from the previous representedObject, 
 BEFORE it is set to nil on my NSViewController.

I think, by using the word through, Ken is suggesting you do this:

[self addObserver:self forKeyPath:@representedObject.incomingNotes 
...];

rather than this:

[self.representedObject addObserver:self forKeyPath:@incomingNotes 
...];

___

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

Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?

[Lee Ann Rucker]

Yes, that approach is *so* much safer. When we switched over to doing it that 
way so many dealloc called while object was being observed problems went away.

- Original Message -
From: Quincey Morris quinceymor...@rivergatesoftware.com
To: Motti Shneor su...@bezeqint.net
Cc: Cocoa-Dev List Cocoa-dev@lists.apple.com
Sent: Sunday, September 9, 2012 4:26:27 PM
Subject: Re: KVO Question: How to programmatically determine if one object is   
observing another on a keyPath and context?

On Sep 9, 2012, at 13:50 , Motti Shneor su...@bezeqint.net wrote:

 On 9 בספט 2012, at 22:04, Ken Thomases wrote:
 
 Why is that a however?  What's the problem?  Since the representedObject 
 is KVO-compliant, all observations _through_ that property will 
 automatically follow it as it changes.
 
 Nope. When representedObject becomes nil, I DO NOT WANT to observe anything, 
 and I need to remove the observance from the previous representedObject, 
 BEFORE it is set to nil on my NSViewController.

I think, by using the word through, Ken is suggesting you do this:

[self addObserver:self forKeyPath:@representedObject.incomingNotes 
...];

rather than this:

[self.representedObject addObserver:self forKeyPath:@incomingNotes 
...];

___

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/lrucker%40vmware.com

This email sent to lruc...@vmware.com

___

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

Re: KVO de-observation difficulties when closing a window

[Jamie Johnson]

Observe NSWindowWillCloseNotification via NSNotificationCenter. You will get 
notified. The delegate should get the notification but it's possible the 
delegate is getting set nil prior. 

On May 13, 2012, at 6:18 PM, Graham Cox wrote:

 This is proving a lot harder that I feel it should be.
 
 I am KVO observing the accessory view property of an NSRulerView, so that I 
 can install different views into the accessory area when the standard text 
 controls are removed. The ownership of the NSRulerView is quite complicated, 
 as it's part of an NSScrollView, which in turn is owned by a bunch of other 
 views and ultimately the window.
 
 I can remove my KVO observation in the window delegate's -windowWillClose: 
 method, and that's fine as far as it goes. But it's not always called, 
 leaving me with the dreaded 'KVO observers were still attached when an object 
 was deallocated' error in some cases (in particular, when the 'Save' dialog 
 shows up and Don't Save is clicked - maybe for other cases as well).
 
 Is there a place I can reliably get notified when a window will close, no 
 matter what pathway it took to close that window, whether a save was 
 involved, whether it was closed by a manual click in the close button or 
 closed by some other means, but BEFORE any of its internal structure is 
 released (views in particular)? Surely there's a reliable place for this?
 
 Ideally I'd prefer a delegate method since I'm not subclassing NSWindow in 
 this case.
 
 
 --Graham
 
 
 
 ___
 
 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/jamiejj%40gmail.com
 
 This email sent to jami...@gmail.com


___

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

[SOLVED] Re: KVO de-observation difficulties when closing a window

[Graham Cox]

Turns out the problem was more complicated than I first though, and I have 
solved it.

-windowWillClose: is reliably called in all cases, whether or not the Save 
dialog gets involved.

The problem was that I was setting up observation in my document's 
-awakeFromNib method, which as we know can be called multiple times. That in 
itself was OK, since the set up did its own checks to avoid observing more than 
once. However, in Lion, document objects get made at odd, surprising times in 
order to support Versions. So a second phantom document object is being made as 
soon as the Save dialog is displayed on the first document. Why Lion does this 
at that moment is something of a mystery, but it does. This second document 
sets up a new observer on a new ruler view, though its window is never 
displayed. As a result, the windowWillClose method of the phantom document 
isn't called and the observation is never cleaned up before the phantom 
document is deallocated. This second document's role in the whole shebang is 
not understood (by me at any rate) - perhaps it's just there to deliver the 
block of data to be saved asynchronously.

Moving all the observation setup to -windowControllerDidLoadNib: instead solves 
the problem, since this does not get invoked for these Lion phantom documents.

It also made me notice a few other potentially problematic setups in 
awakeFromNib that needed moving.

I think the lesson here is that on Lion, you need to allow Cocoa a lot more 
leeway with your document objects that you might be used to on earlier systems. 
I guess it's not unusual to treat your document as a stand-in for a window 
controller, especially as for basic document-based apps you don't need a 
separate window controller subclass, but you have to be aware that Cocoa will 
create these document objects for its own purposes that might conflict with its 
role as a window controller. Lesson learned.


--Graham



On 14/05/2012, at 11:18 AM, Graham Cox wrote:

 This is proving a lot harder that I feel it should be.
 
 I am KVO observing the accessory view property of an NSRulerView, so that I 
 can install different views into the accessory area when the standard text 
 controls are removed. The ownership of the NSRulerView is quite complicated, 
 as it's part of an NSScrollView, which in turn is owned by a bunch of other 
 views and ultimately the window.
 
 I can remove my KVO observation in the window delegate's -windowWillClose: 
 method, and that's fine as far as it goes. But it's not always called, 
 leaving me with the dreaded 'KVO observers were still attached when an object 
 was deallocated' error in some cases (in particular, when the 'Save' dialog 
 shows up and Don't Save is clicked - maybe for other cases as well).
 
 Is there a place I can reliably get notified when a window will close, no 
 matter what pathway it took to close that window, whether a save was 
 involved, whether it was closed by a manual click in the close button or 
 closed by some other means, but BEFORE any of its internal structure is 
 released (views in particular)? Surely there's a reliable place for this?


___

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

Re: KVO willChange and didChange

[Roland King]

Read the section Automatic Change Notification again and understand it has 
nothing to do with properties or dot notation but just the method name. 

Then look up automaticallyNotifiesObserversForKey and turn it off if you want 
to code one key fully manually. 



On 16 Jan, 2012, at 14:30, Gideon King gid...@novamind.com wrote:

 Hi all, when I declare a property, something like:
 
 @property(readwrite, copy, nonatomic) NSString *foo;
 
 I will synthesize it with:
 
 @synthesize foo;
 
 But then I want to do some special processing when the value is set, so I 
 implement my setter:
 
 - (void)setFoo:(NSString *)aFoo {
[self willChangeValueForKey:@foo];
[foo autorelease];
foo = [aFoo retain];
[self didChangeValueForKey:@foo];
[self 
 doSomeMoreProcessingThatShouldHappenAfterAllTheObserversKnowTheNewValue];
 }
 
 I assumed from the documentation and examples that since I was providing my 
 own implementation method, that I would have to include the willChange and 
 didChange methods at appropriate points in my code, but I have just 
 discovered that when I do:
 
 anObject.foo = @something;
 
 I get two prior notifications - one from the internals of the system, and one 
 from my willChange call, and two notifications after the change - one from my 
 didChange and one from the system.
 
 So I thought this must because I used @synthesize as well as providing my own 
 method, so I implemented a getter and removed the @synthesize. The behavior 
 didn't change.
 
 I double checked this by removing my willChange and didChange methods, and 
 now the prior and after notifications only got sent once.
 
 One purpose of mentioning this is that given the fact that I have come across 
 code from several places where they did what I did and had the willChange and 
 didChange code in their setters, others may need to look back at their code 
 and make appropriate changes.
 
 But the big thing for me is that I have a number of places throughout my 
 application where I need to have the changes made, the didChange notification 
 acted on by the observers, and then some other code run.
 
 I therefore wanted to use the setter, but not have to change the name of it, 
 so that bindings would still work, so I changed my property declaration to be 
 readonly, and declared a setFoo: method. I thought that declaring it would 
 make it not call the willChange and didChange behind the scenes, but 
 unfortunately, even with a readonly declaration, when I used anObject.foo = 
 @something, it still called the prior and after KVO methods. So I thought I 
 would explicitly call setFoo: instead of using dot notation, but that made no 
 difference. On the off chance there was something else going on, I also 
 turned off accessesInstanceVariablesDirectly, but that made no difference.
 
 So I thought I would just remove the property declarations altogether, and 
 just code my accessors myself, but it still called the built in KVO methods. 
 
 Therefore my conclusion is that as soon as you add a KVO observation on 
 anything, it triggers the prior and after notifications whenever the setter 
 is called. This of course makes sense, but still leaves me with the original 
 problem: I need some way to have the KVO notifications called *once only*, 
 and yet have my setters able to call other methods after the KVO 
 notifications have been sent. It is not possible for this to be done with 
 performSelector:withObject:afterDelay: or anything similar, since these 
 methods need to be called immediately after the after change notification.
 
 I know I could get it to call the KVO notifications at only the right places 
 by coding my own methods like -(void)changeFooTo:, but I do not want to 
 change the name of my setters because that would break my bindings. 
 
 Are there any recommendations on the best approach for being able to have the 
 setter able to do what it needs with the KVO and then calling other methods, 
 without breaking bindings?
 
 I can't believe I have misunderstood this for so long, and never noticed what 
 was happening until now!
 
 Thanks
 
 Gideon
 
 
 
 
 
 
 
 
 ___
 
 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:
 http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
 
 This email sent to r...@rols.org
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO willChange and didChange

[Stephen J. Butler]

On Mon, Jan 16, 2012 at 12:30 AM, Gideon King gid...@novamind.com wrote:
 Are there any recommendations on the best approach for being able to have the 
 setter able to do what it needs with the KVO and then calling other methods, 
 without breaking bindings?

 I can't believe I have misunderstood this for so long, and never noticed what 
 was happening until now!

From the KVO programming guide, Manual Change Notification:

http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/KeyValueObserving/Articles/KVOCompliance.html#//apple_ref/doc/uid/20002178-SW3
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO willChange and didChange

[Gordon Henriksen]

Try overriding +[NSObject(NSKeyValueObserving) 
automaticallyNotifiesObserversForKey:] to return NO for the properties you want 
to handle manually.

On 2012-01-16, at 01:30, Gideon King wrote:

 Hi all, when I declare a property, something like:
 
 @property(readwrite, copy, nonatomic) NSString *foo;
 
 I will synthesize it with:
 
 @synthesize foo;
 
 But then I want to do some special processing when the value is set, so I 
 implement my setter:
 
 - (void)setFoo:(NSString *)aFoo {
[self willChangeValueForKey:@foo];
[foo autorelease];
foo = [aFoo retain];
[self didChangeValueForKey:@foo];
[self 
 doSomeMoreProcessingThatShouldHappenAfterAllTheObserversKnowTheNewValue];
 }
 
 I assumed from the documentation and examples that since I was providing my 
 own implementation method, that I would have to include the willChange and 
 didChange methods at appropriate points in my code, but I have just 
 discovered that when I do:
 
 anObject.foo = @something;
 
 I get two prior notifications - one from the internals of the system, and one 
 from my willChange call, and two notifications after the change - one from my 
 didChange and one from the system.
 
 So I thought this must because I used @synthesize as well as providing my own 
 method, so I implemented a getter and removed the @synthesize. The behavior 
 didn't change.
 
 I double checked this by removing my willChange and didChange methods, and 
 now the prior and after notifications only got sent once.
 
 One purpose of mentioning this is that given the fact that I have come across 
 code from several places where they did what I did and had the willChange and 
 didChange code in their setters, others may need to look back at their code 
 and make appropriate changes.
 
 But the big thing for me is that I have a number of places throughout my 
 application where I need to have the changes made, the didChange notification 
 acted on by the observers, and then some other code run.
 
 I therefore wanted to use the setter, but not have to change the name of it, 
 so that bindings would still work, so I changed my property declaration to be 
 readonly, and declared a setFoo: method. I thought that declaring it would 
 make it not call the willChange and didChange behind the scenes, but 
 unfortunately, even with a readonly declaration, when I used anObject.foo = 
 @something, it still called the prior and after KVO methods. So I thought I 
 would explicitly call setFoo: instead of using dot notation, but that made no 
 difference. On the off chance there was something else going on, I also 
 turned off accessesInstanceVariablesDirectly, but that made no difference.
 
 So I thought I would just remove the property declarations altogether, and 
 just code my accessors myself, but it still called the built in KVO methods. 
 
 Therefore my conclusion is that as soon as you add a KVO observation on 
 anything, it triggers the prior and after notifications whenever the setter 
 is called. This of course makes sense, but still leaves me with the original 
 problem: I need some way to have the KVO notifications called *once only*, 
 and yet have my setters able to call other methods after the KVO 
 notifications have been sent. It is not possible for this to be done with 
 performSelector:withObject:afterDelay: or anything similar, since these 
 methods need to be called immediately after the after change notification.
 
 I know I could get it to call the KVO notifications at only the right places 
 by coding my own methods like -(void)changeFooTo:, but I do not want to 
 change the name of my setters because that would break my bindings. 
 
 Are there any recommendations on the best approach for being able to have the 
 setter able to do what it needs with the KVO and then calling other methods, 
 without breaking bindings?
 
 I can't believe I have misunderstood this for so long, and never noticed what 
 was happening until now!
 
 Thanks
 
 Gideon
 
 
 
 
 
 
 
 
 ___
 
 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:
 http://lists.apple.com/mailman/options/cocoa-dev/gordonhenriksen%40me.com
 
 This email sent to gordonhenrik...@me.com

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO willChange and didChange

[Gideon King]

Cool, thanks everybody. Nice that there is such a simple solution.


Regards

Gideon


On 16/01/2012, at 4:41 PM, Gordon Henriksen wrote:

 Try overriding +[NSObject(NSKeyValueObserving) 
 automaticallyNotifiesObserversForKey:] to return NO for the properties you 
 want to handle manually.
 

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO willChange and didChange

[Jens Alfke]

On Jan 15, 2012, at 10:41 PM, Gordon Henriksen wrote:

 Try overriding +[NSObject(NSKeyValueObserving) 
 automaticallyNotifiesObserversForKey:] to return NO for the properties you 
 want to handle manually.

Or just don’t call will/DidChange in your setter methods. You don’t need them 
there — KVO automatically does that for you when a setter is called.

What will/DidChange are for is when you change a property’s value without 
invoking its setter. So if you had some code elsewhere that caused the value of 
the .foo property to change, you’d wrap those methods around the change. 
Obviously in your case you should just call setFoo instead, but there are cases 
when a property’s value isn’t stored explicitly as a variable, but is computed 
by the accessor method. So there’s no explicit variable and no sense in having 
a setter, but the value of the getter does change, and you have to let KVO know 
that.

—Jens___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO willChange and didChange

[Roland King]

You missed this in the original mail. 

But the big thing for me is that I have a number of places throughout my 
application where I need to have the changes made, the didChange notification 
acted on by the observers, and then some other code run.

Which is why he wants to manually emit KVO notifications in a standardly-named 
setter so he can put more code after the didChangeValueForKey: before the 
setter returns. 

I'd say having code which depends on that ordering is a bit suspect, but if 
that's what he wants, removing the automatic notifications and doing it himself 
is ok. 



On 16 Jan, 2012, at 15:13, Jens Alfke j...@mooseyard.com wrote:

 
 On Jan 15, 2012, at 10:41 PM, Gordon Henriksen wrote:
 
 Try overriding +[NSObject(NSKeyValueObserving) 
 automaticallyNotifiesObserversForKey:] to return NO for the properties you 
 want to handle manually.
 
 Or just don’t call will/DidChange in your setter methods. You don’t need them 
 there — KVO automatically does that for you when a setter is called.
 
 What will/DidChange are for is when you change a property’s value without 
 invoking its setter. So if you had some code elsewhere that caused the value 
 of the .foo property to change, you’d wrap those methods around the change. 
 Obviously in your case you should just call setFoo instead, but there are 
 cases when a property’s value isn’t stored explicitly as a variable, but is 
 computed by the accessor method. So there’s no explicit variable and no sense 
 in having a setter, but the value of the getter does change, and you have to 
 let KVO know that.
 
 —Jens___
 
 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:
 http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
 
 This email sent to r...@rols.org
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO Setting a flag for any property change

[Keary Suska]

On Dec 14, 2011, at 6:29 AM, Andre Masse wrote:

 I have a superclass which has a modified BOOL property and a bunch of 
 subclasses based on it. When any property is changed, I need to set this flag 
 to YES. I can either write a setter for all properties and set this flag 
 there, or observe all properties and set the flag in -observeValueForKeyPath. 
 Both approach involve a lot of boilerplate coding (some subclasses have 20+ 
 properties).
 
 I thought about using -keyPathsForValuesAffectingModified: but I don't see 
 how I can set a flag using this.


This kind of approach is probably best unless you can base your superclass on 
NSManagedObject, which does this automatically. But, as you find, there is some 
difficulty. I would have a pseudo-flag, say hasBeenModified, and implement 
+keyPathsForValuesAffectingHasBeenModified:. In -hasBeenModified simply set the 
flag KVO-compliantly. You mat want to check the flag to avoid unnecessary KVO 
calls.

HTH.

Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO Setting a flag for any property change

[Andre Masse]

Clever! Thanks for the suggestion.


Andre Masse

Keary Suska mailto:cocoa-...@esoteritech.com
December 14, 2011 10:56


This kind of approach is probably best unless you can base your 
superclass on NSManagedObject, which does this automatically. But, as 
you find, there is some difficulty. I would have a pseudo-flag, say 
hasBeenModified, and implement 
+keyPathsForValuesAffectingHasBeenModified:. In -hasBeenModified 
simply set the flag KVO-compliantly. You mat want to check the flag to 
avoid unnecessary KVO calls.


HTH.

Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business


Andre Masse mailto:andre.ma...@videotron.ca
December 14, 2011 08:29
Hi,

I have a superclass which has a modified BOOL property and a bunch 
of subclasses based on it. When any property is changed, I need to set 
this flag to YES. I can either write a setter for all properties and 
set this flag there, or observe all properties and set the flag in 
-observeValueForKeyPath. Both approach involve a lot of boilerplate 
coding (some subclasses have 20+ properties).


I thought about using -keyPathsForValuesAffectingModified: but I don't 
see how I can set a flag using this.


Any ideas?

Thanks,

Andre Masse

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO Setting a flag for any property change

[Keary Suska]

On Dec 14, 2011, at 3:21 PM, Andre Masse wrote:

 
 Clever! Thanks for the suggestion.

You probably figured this out but for prosperity there needs to be an observer 
of hasBeenModified, or the object itself can observe hasBeenModified and set 
the flag itself. Just a piece that might not be obvious to some...

 Andre Masse
 Keary Suska mailto:cocoa-...@esoteritech.com
 December 14, 2011 10:56
 
 
 This kind of approach is probably best unless you can base your superclass 
 on NSManagedObject, which does this automatically. But, as you find, there 
 is some difficulty. I would have a pseudo-flag, say hasBeenModified, and 
 implement +keyPathsForValuesAffectingHasBeenModified:. In -hasBeenModified 
 simply set the flag KVO-compliantly. You mat want to check the flag to avoid 
 unnecessary KVO calls.
 
 HTH.
 
 Keary Suska
 Esoteritech, Inc.
 Demystifying technology for your home or business
 
 
 Andre Masse mailto:andre.ma...@videotron.ca
 December 14, 2011 08:29
 Hi,
 
 I have a superclass which has a modified BOOL property and a bunch of 
 subclasses based on it. When any property is changed, I need to set this 
 flag to YES. I can either write a setter for all properties and set this 
 flag there, or observe all properties and set the flag in 
 -observeValueForKeyPath. Both approach involve a lot of boilerplate coding 
 (some subclasses have 20+ properties).
 
 I thought about using -keyPathsForValuesAffectingModified: but I don't see 
 how I can set a flag using this.


Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO Setting a flag for any property change

[Andre Masse]

Thanks for pointing this out.

Andre Masse


Keary Suska mailto:cocoa-...@esoteritech.com
December 14, 2011 21:03
On Dec 14, 2011, at 3:21 PM, Andre Masse wrote:


Clever! Thanks for the suggestion.


You probably figured this out but for prosperity there needs to be an observer of 
hasBeenModified, or the object itself can observe hasBeenModified and set the 
flag itself. Just a piece that might not be obvious to some...


Andre Masse

Keary Suskamailto:cocoa-...@esoteritech.com
December 14, 2011 10:56


This kind of approach is probably best unless you can base your superclass on 
NSManagedObject, which does this automatically. But, as you find, there is some 
difficulty. I would have a pseudo-flag, say hasBeenModified, and implement 
+keyPathsForValuesAffectingHasBeenModified:. In -hasBeenModified simply set the flag 
KVO-compliantly. You mat want to check the flag to avoid unnecessary KVO calls.

HTH.

Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business


Andre Massemailto:andre.ma...@videotron.ca
December 14, 2011 08:29
Hi,

I have a superclass which has a modified BOOL property and a bunch of 
subclasses based on it. When any property is changed, I need to set this flag to YES. I 
can either write a setter for all properties and set this flag there, or observe all 
properties and set the flag in -observeValueForKeyPath. Both approach involve a lot of 
boilerplate coding (some subclasses have 20+ properties).

I thought about using -keyPathsForValuesAffectingModified: but I don't see how 
I can set a flag using this.



Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business


Andre Masse mailto:andre.ma...@videotron.ca
December 14, 2011 17:21

Clever! Thanks for the suggestion.


Andre Masse
Keary Suska mailto:cocoa-...@esoteritech.com
December 14, 2011 10:56


This kind of approach is probably best unless you can base your 
superclass on NSManagedObject, which does this automatically. But, as 
you find, there is some difficulty. I would have a pseudo-flag, say 
hasBeenModified, and implement 
+keyPathsForValuesAffectingHasBeenModified:. In -hasBeenModified 
simply set the flag KVO-compliantly. You mat want to check the flag to 
avoid unnecessary KVO calls.


HTH.

Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business


Andre Masse mailto:andre.ma...@videotron.ca
December 14, 2011 08:29
Hi,

I have a superclass which has a modified BOOL property and a bunch 
of subclasses based on it. When any property is changed, I need to set 
this flag to YES. I can either write a setter for all properties and 
set this flag there, or observe all properties and set the flag in 
-observeValueForKeyPath. Both approach involve a lot of boilerplate 
coding (some subclasses have 20+ properties).


I thought about using -keyPathsForValuesAffectingModified: but I don't 
see how I can set a flag using this.


Any ideas?

Thanks,

Andre Masse

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO on objects in NSArrayController

[Sean McBride]

On Sat, 3 Sep 2011 09:23:43 -0700, Kyle Sluder said:

 I understand that... I think the alternative would be to register an
 observer on all 8000+ objects in the array.

Yes, this is the expected pattern with KVO. Contrary to what you might
think at first, it is *fast*.

Unless you are using garbage collection, in which case it is an order of 
magnitude slower than with MRC (manual ref counting).  ie horribly slow.

--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO on objects in NSArrayController

[Jerry Krinock]

On 2011 Sep 02, at 22:22, Trygve Inda wrote:

 Briefly, you can configure the checkbox cell (either in IB or
 programmatically) to have an action…

 I think this sounds like a much better option than trying to use KVO.

Indeed it is, *if* you literally want the notification, as you said in your 
original post, whenever the user toggles a … checkbox.

However, if, as is more commonly the case, you actually need a notification 
whenever the 'marked' attribute in the data model changes, and if your 
application provides any other means by which that attribute could be changed, 
such as Undo, scriptability, business logic, or some other view of that 
attribute, which may be added in the future, then the shortcut of wiring to the 
control's action, although convenient, is going to be be missing these changes.

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO on objects in NSArrayController

[Trygve Inda]

 
 On 2011 Sep 02, at 22:22, Trygve Inda wrote:
 
 Briefly, you can configure the checkbox cell (either in IB or
 programmatically) to have an action…
 
 I think this sounds like a much better option than trying to use KVO.
 
 Indeed it is, *if* you literally want the notification, as you said in your
 original post, whenever the user toggles a … checkbox.
 
 However, if, as is more commonly the case, you actually need a notification
 whenever the 'marked' attribute in the data model changes, and if your
 application provides any other means by which that attribute could be changed,
 such as Undo, scriptability, business logic, or some other view of that
 attribute, which may be added in the future, then the shortcut of wiring to
 the control's action, although convenient, is going to be be missing these
 changes.

I understand that... I think the alternative would be to register an
observer on all 8000+ objects in the array.

For now however, the checkbox is the only way to alter the marked state so
this should work.

Thanks!



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO on objects in NSArrayController

[Quincey Morris]

On Sep 2, 2011, at 23:34 , Jerry Krinock wrote:

 Indeed it is, *if* you literally want the notification, as you said in your 
 original post, whenever the user toggles a … checkbox.

Sure.

 However, if, as is more commonly the case, you actually need a notification 
 whenever the 'marked' attribute in the data model changes, and if your 
 application provides any other means by which that attribute could be 
 changed, such as Undo, scriptability, business logic, or some other view of 
 that attribute, which may be added in the future, then the shortcut of wiring 
 to the control's action, although convenient, is going to be be missing these 
 changes.

I think characterizing it as more commonly the case is going too far. If it 
were really true that the most common KVO case made it desirable to observe 
thousands of individual objects (as opposed to observing or watching something 
less numerous), then we'd see a lot more complaining about KVO on this list. :)

I'd say the opposite is true -- the absolute need to observe properties of 
every individual object in an array (especially a large array) is rare enough 
that it's not a great hindrance to the usefulness of KVO generally.

Still, in the scenario you raise, where there's a big array and it doesn't seem 
feasible to observe everything in the array, then I would look for a solution 
that produces KVO notifications for the array itself. That is, rather than 
generating a KVO notification for 'array [n].object.property changed', I'd 
arrange to generate a KVO notification for 'array object at index n was 
replaced'. (And in fact, I've written code like this. Unfortunately, it's a bit 
tricky to get it right.)

OTOH, doing this may well fall under the heading of premature optimization. We 
don't have any a priori reason to assume that setting up tens of thousands of 
observations is infeasible, or a performance or resource bottleneck.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO on objects in NSArrayController

[Dave Fernandes]

I'm coming late to this conversation, but couldn't you just add a -[MyObject  
setMarked:] method that would then be called to change the 'marked' 
attribute/property? It can do anything else it wants after making the change. 
Why use notifications at all? Is it some other object that needs to be notified 
when MyObject changes?

On 2011-09-03, at 1:22 AM, Trygve Inda wrote:

 On Sep 2, 2011, at 19:01 , Trygve Inda wrote:
 
 I have an array of objects (of class MyObject) managed by an
 NSArrayController and displayed in an NSTable (via bindings).
 
 One property of MyObject is a BOOL marked.
 
 I need to be notified whenever the user toggles a marked checkbox in my
 NSTable.
 
 What is the best way to do this? Do I need to add an observer to every
 object in the array (there are about 8,000 of them).
 
 How can I best achieve this so that I get passed the changed MyObject
 (immediately after it changes).
 
 Briefly, you can configure the checkbox cell (either in IB or
 programmatically) to have an action, and possibly an explicit target. In the
 action method, you can use NSTableView's 'clickedRow' method to find the row
 and hence the object whose marked property changed, and send a message
 representing to the change directly to whatever object has to be notified.
 
 
 
 I think this sounds like a much better option than trying to use KVO.
 Thanks!
 
 
 
 ___
 
 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:
 http://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
 
 This email sent to dave.fernan...@utoronto.ca

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO on objects in NSArrayController

[Jerry Krinock]

On 2011 Sep 03, at 07:34, Dave Fernandes wrote:

 I'm coming late to this conversation, but couldn't you just add a -[MyObject  
 setMarked:] method that would then be called to change the 'marked' 
 attribute/property? It can do anything else it wants after making the change. 
 Why use notifications at all? Is it some other object that needs to be 
 notified when MyObject changes?

Yes.  The reason I use the notification is, of course, the same reason you 
always using a notification, because the observer is not known to the observee, 
and/or it makes for nicer encapsulation.  But if you didn't have these reasons, 
indeed a simple message would work.

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO on objects in NSArrayController

[Dave Fernandes]

I agree, it is certainly a valid and useful design pattern that I use as well. 
But I just wasn't sure that it is needed in the OP's case. From the part that I 
read (and I missed the first part of the thread), there was no mention of which 
objects needed to be notified.

On 2011-09-03, at 10:52 AM, Jerry Krinock wrote:

 
 On 2011 Sep 03, at 07:34, Dave Fernandes wrote:
 
 I'm coming late to this conversation, but couldn't you just add a -[MyObject 
  setMarked:] method that would then be called to change the 'marked' 
 attribute/property? It can do anything else it wants after making the 
 change. Why use notifications at all? Is it some other object that needs to 
 be notified when MyObject changes?
 
 Yes.  The reason I use the notification is, of course, the same reason you 
 always using a notification, because the observer is not known to the 
 observee, and/or it makes for nicer encapsulation.  But if you didn't have 
 these reasons, indeed a simple message would work.
 
 ___
 
 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:
 http://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
 
 This email sent to dave.fernan...@utoronto.ca

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO on objects in NSArrayController

[Kyle Sluder]

On Sat, Sep 3, 2011 at 12:12 AM, Trygve Inda cocoa...@xericdesign.com wrote:
 I understand that... I think the alternative would be to register an
 observer on all 8000+ objects in the array.

Yes, this is the expected pattern with KVO. Contrary to what you might
think at first, it is *fast*.

To use OmniPlan 2 as an example, each cell in each row in the outline
view registers itself as an observer of one property of the model
object (actually a controller-layer proxy). The row itself registers
as a KVO observer of a few other properties of that proxy. OmniPlan 2
documents usually have a few hundred if not thousands of rows.

We have never seen any of the KVO implementation functions appear in
our sample reports during performance testing.

In fact, KVO is *much* faster than using NSNotificationCenter for the
same purpose. But sending one NSNotification is much faster than
sending 8,000 KVO notifications.

So do what's right for the situation at hand. If you need to know
about the marked property of 8,000 objects, register yourself as a
KVO observer for each of those 8,000 objects.

--Kyle Sluder


 For now however, the checkbox is the only way to alter the marked state so
 this should work.

 Thanks!



 ___

 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:
 http://lists.apple.com/mailman/options/cocoa-dev/kyle.sluder%40gmail.com

 This email sent to kyle.slu...@gmail.com

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO on objects in NSArrayController

[Jerry Krinock]

On 2011 Sep 02, at 19:01, Trygve Inda wrote:

 What is the best way to do this? Do I need to add an observer to every
 object in the array (there are about 8,000 of them).

If you want to use KVO, yes.  I recall some sample code, written by mmalc.  I 
forgot if it was on stepwise.com (which means it's no longer available) or on 
developer.apple.com.  I think the concept is explained in Apple's KVO 
Programming Guide or whatever.

Now, the reason why my memory fails me is because I don't do it this way.  When 
I find myself needing to do gymnastics like that with KVO, I use old-fashioned 
NSNotification/Center/Queue instead.  There are still gymnastics, but maybe 
only half as much.  Most importantly, when a observer is going away, you can 
remove all of its observations with one line of code, invoking 
-[NSNotificationCenter removeObserver:].  If I recall correctly, with KVO you 
need to do careful accounting and remove each key path of each observed object. 
 Any mistakes and you'll get KVO observations sent to dead objects; at least an 
exception and often a crash.  No matter how few bugs you produce in an average 
day, you're going to have relatively fewer of them with one line of code.  
There is still the matter of where to put that line of code, because -dealloc 
is often too late, but you have the same issue KVO, and if this business was 
easy, everybody would be in it :))

In your particular case, you'd have your observer register for a notification 
named, for example TrygveMyObjectWasMarked, and post this notification in an 
override of -[MyObject setIsMarked:].

 How can I best achieve this so that I get passed the changed MyObject
 (immediately after it changes).

Pass it as the notification object or in the userInfo.  Your desire to have it 
happen immediately is another topic.  To get some control over how fast is 
immediate, you can use NSNotificationQueue and adjust the posting style.  If 
performance becomes an issue, careful coalescing of notifications can usually 
fix it.

I'll be interested to see if anyone posts any other ideas, or disadvantages of 
my design pattern which I've overlooked.

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO on objects in NSArrayController

[Quincey Morris]

On Sep 2, 2011, at 19:01 , Trygve Inda wrote:

 I have an array of objects (of class MyObject) managed by an
 NSArrayController and displayed in an NSTable (via bindings).
 
 One property of MyObject is a BOOL marked.
 
 I need to be notified whenever the user toggles a marked checkbox in my
 NSTable.
 
 What is the best way to do this? Do I need to add an observer to every
 object in the array (there are about 8,000 of them).
 
 How can I best achieve this so that I get passed the changed MyObject
 (immediately after it changes).

Briefly, you can configure the checkbox cell (either in IB or programmatically) 
to have an action, and possibly an explicit target. In the action method, you 
can use NSTableView's 'clickedRow' method to find the row and hence the object 
whose marked property changed, and send a message representing to the change 
directly to whatever object has to be notified.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO on objects in NSArrayController

[Trygve Inda]

 On Sep 2, 2011, at 19:01 , Trygve Inda wrote:
 
 I have an array of objects (of class MyObject) managed by an
 NSArrayController and displayed in an NSTable (via bindings).
 
 One property of MyObject is a BOOL marked.
 
 I need to be notified whenever the user toggles a marked checkbox in my
 NSTable.
 
 What is the best way to do this? Do I need to add an observer to every
 object in the array (there are about 8,000 of them).
 
 How can I best achieve this so that I get passed the changed MyObject
 (immediately after it changes).
 
 Briefly, you can configure the checkbox cell (either in IB or
 programmatically) to have an action, and possibly an explicit target. In the
 action method, you can use NSTableView's 'clickedRow' method to find the row
 and hence the object whose marked property changed, and send a message
 representing to the change directly to whatever object has to be notified.
 
 

I think this sounds like a much better option than trying to use KVO.
Thanks!



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: kvo

[Ken Tozier]

Have you tried NSInvocationOperations? They allow you to queue up your own 
handler and you could do any required checking in that

Something like

// init requestQueue in your class's init method
// then whenever you need to queue up a url load
// do something like this

- (void) queueRequest:(NSURL *) inRequest
{
NSInvocationOperation   *operation  = [[[NSInvocationOperation 
alloc] 

initWithTarget: self

selector: @selector(performRequest:) 

object: inRequest]

autorelease];
[operation addObserver: self
forKeyPath: @isFinished
options: NSKeyValueObservingOptionNew
context: NULL];

[operation addObserver: self
forKeyPath: @isCancelled
options: NSKeyValueObservingOptionNew // not sure if 
this it the right option here, You'd have to check
context: NULL];

[requestQueue addOperation: operation];
}


- (void) performRequest:(NSURL *) inRequest
{
// do your thing with the url, including checking for validity
// in this method
}

- (void)observeValueForKeyPath:(NSString *) inKeyPath 
ofObject:(id) inObject 
change:(NSDictionary *) inChange 
context:(void *) inContext
{
[inObject removeObserver: self forKeyPath: @isFinished];
[inObject removeObserver: self forKeyPath: @isCancelled];

if ([inKeyPath isEqualToString: @isFinished])
{
// do your thing with successes
}
else if ([inKeyPath isEqualToString: @isCancelled])
{
// do your thing with failures
}
}



On Jun 13, 2011, at 8:52 PM, Ariel Feinerman wrote:

 Hi,
 
 how to cancel operation which is performing?
 
 I think it is not safe:
 
 - (void) beginOperation {
 
 [_operation cancel];
 
 _operation = [[Operation alloc] initWithURL: [NSURL URLWithString: @
 http://rss.cnn.com/rss/cnn_topstories.xml;]];
 
 _queue = [NSOperationQueue new];
 
 [_operation addObserver: self forKeyPath: @isFinished options:
 NSKeyValueObservingOptionNew context: NULL];
 
 [_operation addObserver: self forKeyPath: @isCancelled options:
 NSKeyValueObservingOptionNew context: NULL];
 
 [_queue addOperation: _operation];
 
 }
 
 
 - (void) observeValueForKeyPath: (NSString *) keyPath ofObject: (id) object
 
 change: (NSDictionary *) change context: (void *) context {
 
 if ([keyPath isEqualToString: @isFinished]) {
 
 if ([[change valueForKey: NSKeyValueChangeNewKey] boolValue]) {
 
  [rootViewController performSelectorOnMainThread: @selector(setItemList:)
 withObject: [_operation itemList] waitUntilDone: NO];
 
 static BOOL firstTime = YES;
 
 if (firstTime) {
 
 [self performSelectorOnMainThread: @selector(setRootView:) withObject: nil
 waitUntilDone: NO];
 
 firstTime = NO;
 
 }
 
 }
 
 }
 
 else if ([keyPath isEqualToString: @isCancelled]) {
 
 if ([[change valueForKey: NSKeyValueChangeNewKey] boolValue]) {
 
 if ([_operation error]) {
 
 [self performSelectorOnMainThread: @selector(errorOccurs:) withObject:
 [_operation error] waitUntilDone: NO];
 
 }
 
 }
 
 }
 
 [_operation removeObserver: self forKeyPath: @isFinished];
 
 [_operation removeObserver: self forKeyPath: @isCancelled];
 
 [_operation release];
 
 _operation = nil;
 
 [_queue release];
 
 _queue = nil;
 
 }
 
 -- 
 best regards
 Ariel
 ___
 
 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:
 http://lists.apple.com/mailman/options/cocoa-dev/kentozier%40comcast.net
 
 This email sent to kentoz...@comcast.net

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: kvo

[Matt Neuburg]

On Tue, 08 Mar 2011 01:23:18 +0200, Ariel Feinerman arielfap...@gmail.com 
said:
Hi,

I wish to use kvo to get data from NSOperation and observe isFinished but on
witch thread is - observeValueForKeyPath:ofObject:change:context: executed?

Why not use NSLog and find out? :)

Basically, you shouldn't make *any* assumptions about this. If you need to do 
something in response to isFinished that has to be on a particular thread (such 
as the main thread), then jump out to that thread in your implementation of 
observeValueForKeyPath:...

The same is true if you post a notification from the NSOperation.

m.

--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: kvo

[Kyle Sluder]

On Mon, Mar 7, 2011 at 3:23 PM, Ariel Feinerman arielfap...@gmail.com wrote:
 Hi,

 I wish to use kvo to get data from NSOperation and observe isFinished but on
 witch thread is - observeValueForKeyPath:ofObject:change:context: executed?

From the NSOperation documentation:

Although you can attach observers to these properties, you should not
use Cocoa bindings to bind them to elements of your application’s user
interface. Code associated with your user interface typically must
execute only in your application’s main thread. Because an operation
may execute in any thread, KVO notifications associated with that
operation may similarly occur in any thread.

--Kyle Sluder
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Michael Swan]

Gideon,
It looks like you have an NSManagedObject that is observing itself. If this is 
in fact the case what is the objective? There may be a better way to accomplish 
your goal if you let us know what it is.


Mike Swan
ETCP Certified Entertainment Electrician
http://www.michaelsswan.com

As human beings our greatness lies not so much in being able to remake the 
world... as being able to remake ourselves  - Gandhi



On Aug 9, 2010, at 6:59 AM, cocoa-dev-requ...@lists.apple.com wrote:

 Message: 15
 Date: Mon, 9 Aug 2010 20:51:44 +1000
 From: Gideon King gid...@novamind.com
 Subject: KVO and Core data
 To: cocoa-dev List cocoa-dev@lists.apple.com
 Message-ID: 55ff7ff0-18be-4e88-93b5-28d1da2bf...@novamind.com
 Content-Type: text/plain; charset=us-ascii
 
 Hi all,
 
 I have a KVO registration like this:
 
 [self addObserver:self forKeyPath:@toOne.attribute options:0 context:NULL];
 
 I establish this on -awakeFromInsert or -awakeFromFetch, and have the 
 corresponding removeObserver called on -willTurnIntoFault.
 
 The problem is that when I do a Save As on my document, it migrates the 
 persistent store, which appears to cause the object at the destination of the 
 toOne relationship to be turned into a fault before the object that 
 registered as an observer is. Now when I check the observationInfo for the 
 object that is being faulted (at the end of the toOne relationship), it has 
 itself registered as an observer for attribute. 
 
 I guess this means that behind the scenes, the KVO establishes observation 
 information automatically at every level of a key path (something I hadn't 
 realized before, but which appears to make sense). 
 
 Then something behind the scenes tries to access the attribute on an object 
 that has been turned into a fault, and invalidated, and everything comes 
 crashing down.
 
 So I have two questions:
 
 1. Is it the right way for me to be adding observation on the awake methods 
 and removing it on willTurnToFault?
 
 2. If this is OK, then what could be affecting the system such that it 
 doesn't remove the observation information in the destination of the to-one 
 relationship? I'm wondering if there could be something in my data model that 
 could be affecting it. This relationship is modeled as a one to one, with a 
 delete rule of cascade from the parent to the child, and the inverse 
 relationship is also modeled, with a deny rule. There's also another optional 
 relationship from the child to the parent with a deny rule, modeled in one 
 direction only (and not used in the data I am testing with anyway).
 
 
 A sample trace:
 
 The NSManagedObject with ID:0x1240033c0 
 x-coredata://53D12C5C-31DB-4287-89B2-E03CF59EB066/TopicMapView/pDC99795E-2B94-4721-BCFF-AB3945EC74D2
  has been invalidated.
 0   CoreFoundation  0x7fff88f0fcc4 
 __exceptionPreprocess + 180
 1   libobjc.A.dylib 0x7fff823880f3 
 objc_exception_throw + 45
 2   CoreData0x7fff8836911a 
 -[_NSInvalidationFaultHandler fulfillFault:withContext:] + 106
 3   CoreData0x7fff8830bdbe 
 _PF_FulfillDeferredFault + 254
 4   CoreData0x7fff8830fab7 
 _sharedIMPL_pvfk_core + 87
 5   CoreData0x7fff8830fc28 
 -[NSManagedObject(_PFDynamicAccessorsAndPropertySupport) 
 _genericValueForKey:withIndex:flags:] + 40
 6   CoreData0x7fff883154be -[NSManagedObject 
 valueForKey:] + 270
 7   Foundation  0x7fff868594e5 
 -[NSKeyValueNestedProperty object:didRemoveObservance:recurse:] + 86
 8   Foundation  0x7fff86858d3b 
 -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] + 190
 9   Foundation  0x7fff86858c1f 
 -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] + 135
 10  Foundation  0x7fff86859502 
 -[NSKeyValueNestedProperty object:didRemoveObservance:recurse:] + 115
 11  Foundation  0x7fff86858d3b 
 -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] + 190
 12  Foundation  0x7fff86858c1f 
 -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] + 135
 13  NMFoundation0x0001002bbe6f -[NMTopicNodeMO 
 stopObserving] + 279
 14  NMFoundation0x0001002b1f23 -[NMManagedObject 
 willTurnIntoFault] + 235
 15  NMFoundation0x0001002bc070 -[NMTopicNodeMO 
 willTurnIntoFault] + 347
 16  CoreData0x7fff88316be0 -[NSFaultHandler 
 turnObject:intoFaultWithContext:] + 96
 17  CoreData0x7fff88316572 
 -[NSManagedObjectContext reset] + 578
 18  CoreData0x7fff8836e0d3 
 -[NSPersistentStoreCoordinator(_NSInternalMethods) 
 

Re: KVO and Core data

[Gideon King]

The objective is for me to be notified when toOne.attribute changes (either 
by toOne changing or by the attribute changing).

Surely what I am doing is not getting the NSManagedObject to observe itself, 
but rather the observer is self and the observee is the to one relationship 
and it's attribute.

If I made it [toOne addObserver:self forKeyPath:@attribute options:0 
context:NULL], then I would have to separately keep track of when toOne 
changed, and update the observers, and also this is a simple case - sometimes I 
need to do toOne.toOne.attribute.

Or maybe I'm missing something in how KVO works with key paths...

Gideon


On 09/08/2010, at 9:24 PM, Michael Swan wrote:

 Gideon,
 It looks like you have an NSManagedObject that is observing itself. If this 
 is in fact the case what is the objective? There may be a better way to 
 accomplish your goal if you let us know what it is.
 
 
 [self addObserver:self forKeyPath:@toOne.attribute options:0 context:NULL];
 
 

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Dave Fernandes]

Why does the object need to be notified of changes? Is it to change its own 
attributes in response? If so, you can define the class method
+ (NSSet*)keyPathsForValuesAffectingKey

There is no observer to set up or remove.

Dave

On 2010-08-09, at 8:42 AM, Gideon King wrote:

 The objective is for me to be notified when toOne.attribute changes (either 
 by toOne changing or by the attribute changing).
 
 Surely what I am doing is not getting the NSManagedObject to observe itself, 
 but rather the observer is self and the observee is the to one relationship 
 and it's attribute.
 
 If I made it [toOne addObserver:self forKeyPath:@attribute options:0 
 context:NULL], then I would have to separately keep track of when toOne 
 changed, and update the observers, and also this is a simple case - sometimes 
 I need to do toOne.toOne.attribute.
 
 Or maybe I'm missing something in how KVO works with key paths...
 
 Gideon
 
 
 On 09/08/2010, at 9:24 PM, Michael Swan wrote:
 
 Gideon,
 It looks like you have an NSManagedObject that is observing itself. If this 
 is in fact the case what is the objective? There may be a better way to 
 accomplish your goal if you let us know what it is.
 
 
 [self addObserver:self forKeyPath:@toOne.attribute options:0 
 context:NULL];
 
 
 
 ___
 
 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:
 http://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
 
 This email sent to dave.fernan...@utoronto.ca

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Keary Suska]

On Aug 9, 2010, at 4:51 AM, Gideon King wrote:

 Hi all,
 
 I have a KVO registration like this:
 
 [self addObserver:self forKeyPath:@toOne.attribute options:0 context:NULL];
 
 I establish this on -awakeFromInsert or -awakeFromFetch, and have the 
 corresponding removeObserver called on -willTurnIntoFault.
 
 The problem is that when I do a Save As on my document, it migrates the 
 persistent store, which appears to cause the object at the destination of the 
 toOne relationship to be turned into a fault before the object that 
 registered as an observer is. Now when I check the observationInfo for the 
 object that is being faulted (at the end of the toOne relationship), it has 
 itself registered as an observer for attribute. 
 
 I guess this means that behind the scenes, the KVO establishes observation 
 information automatically at every level of a key path (something I hadn't 
 realized before, but which appears to make sense). 

Yes.

 Then something behind the scenes tries to access the attribute on an object 
 that has been turned into a fault, and invalidated, and everything comes 
 crashing down.

The trace shows that the destination has been invalidated before your object is 
faulted, and so the exception is raised when it tries to remove observation. 
Invalidated object references should be rare--I would expect Core Data to 
clean up relationships when a MOC is reset but that does not appear to be the 
case (at least not all the time). Have you re-looked at the issues around the 
question you asked back in April: 
http://www.cocoabuilder.com/archive/cocoa/284398-invalidated-managed-objects.html
 ?

If that doesn't help, the easiest workaround I can think of is have the 
destination observe its attribute, and then call a method on all objects from 
the inverse to-many.

 So I have two questions:
 
 1. Is it the right way for me to be adding observation on the awake methods 
 and removing it on willTurnToFault?

For cross-relationship KVO, generally yes.

Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Dave Fernandes]

On 2010-08-09, at 10:20 AM, Keary Suska wrote:

 
 So I have two questions:
 
 1. Is it the right way for me to be adding observation on the awake 
 methods and removing it on willTurnToFault?
 
 For cross-relationship KVO, generally yes.

Objects can turn into faults and then be refetched. Not sure if 
awakeFromSnapshotEvents: covers all these cases. In any case, this is only 
useful on 10.6 or later. For earlier OS versions, you will have a problem with 
the above design pattern if an object is, say, deleted and then the deletion is 
undone.___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Gideon King]

Thanks Keary and Dave

Yes, Ben helped me a lot with sorting out the underlying issues, which turned 
out to be a number of misunderstandings about what various methods in the 
atomic store are supposed to do, what is required, etc etc. And at the time, we 
had got to a point where we could save, save as, open and save, and it all 
worked, but this is the first time we have revisited the whole file saving 
thing after making a bunch of changes to the model and lots of KVO stuff, and 
either there were inherent problems that we didn't see before because we 
weren't observing attributes like this, or we may have introduced issues that 
weren't there before.

Dave's idea of using + (NSSet*)keyPathsForValuesAffectingKey may help in some 
situations, but I don't think it's practical for all, especially where I'm 
using KVO for my front end to observe changes in the back end and react, where 
I sometimes need to know the before and after values. I'd have to think about 
that some more...

I hadn't thought about the faulting and refetching issue, and I do need to 
support 10.5, so don't have the awakeFromSnapshotEvents available to me.

So, still a little uncertain on the best solution for my situation...

Regards

Gideon

On 10/08/2010, at 12:20 AM, Keary Suska wrote:

 
 The trace shows that the destination has been invalidated before your object 
 is faulted, and so the exception is raised when it tries to remove 
 observation. Invalidated object references should be rare--I would expect 
 Core Data to clean up relationships when a MOC is reset but that does not 
 appear to be the case (at least not all the time). Have you re-looked at the 
 issues around the question you asked back in April: 
 http://www.cocoabuilder.com/archive/cocoa/284398-invalidated-managed-objects.html
  ?
 
 If that doesn't help, the easiest workaround I can think of is have the 
 destination observe its attribute, and then call a method on all objects from 
 the inverse to-many.
 
 So I have two questions:
 
 1. Is it the right way for me to be adding observation on the awake 
 methods and removing it on willTurnToFault?
 
 For cross-relationship KVO, generally yes.
 
 Keary Suska
 Esoteritech, Inc.
 Demystifying technology for your home or business
 

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Dave Fernandes]

On 2010-08-09, at 11:13 AM, Gideon King wrote:

 Dave's idea of using + (NSSet*)keyPathsForValuesAffectingKey may help in 
 some situations, but I don't think it's practical for all, especially where 
 I'm using KVO for my front end to observe changes in the back end and react, 
 where I sometimes need to know the before and after values. I'd have to think 
 about that some more...

Actually, it's particularly effective for keeping the UI updated and works with 
bindings. You provide an accessor method for your attribute and when called, 
the method first checks toOne's attributes that it depends on and then updates 
itself to be consistent before returning the new value. However, if you want 
the 'before' value, you will need your own caching/messaging in there 
somewhere. How is this information used?

Dave___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Quincey Morris]

On Aug 9, 2010, at 08:13, Gideon King wrote:

 Yes, Ben helped me a lot with sorting out the underlying issues, which turned 
 out to be a number of misunderstandings about what various methods in the 
 atomic store are supposed to do, what is required, etc etc. And at the time, 
 we had got to a point where we could save, save as, open and save, and it all 
 worked, but this is the first time we have revisited the whole file saving 
 thing after making a bunch of changes to the model and lots of KVO stuff, and 
 either there were inherent problems that we didn't see before because we 
 weren't observing attributes like this, or we may have introduced issues that 
 weren't there before.
 
 Dave's idea of using + (NSSet*)keyPathsForValuesAffectingKey may help in 
 some situations, but I don't think it's practical for all, especially where 
 I'm using KVO for my front end to observe changes in the back end and react, 
 where I sometimes need to know the before and after values. I'd have to think 
 about that some more...
 
 I hadn't thought about the faulting and refetching issue, and I do need to 
 support 10.5, so don't have the awakeFromSnapshotEvents available to me.
 
 [...]
 
 On 10/08/2010, at 12:20 AM, Keary Suska wrote:
 
 
 The trace shows that the destination has been invalidated before your object 
 is faulted, and so the exception is raised when it tries to remove 
 observation. Invalidated object references should be rare--I would expect 
 Core Data to clean up relationships when a MOC is reset but that does not 
 appear to be the case (at least not all the time). Have you re-looked at the 
 issues around the question you asked back in 
 April:http://www.cocoabuilder.com/archive/cocoa/284398-invalidated-managed-objects.html
  ?

But you haven't addressed Keary's excellent point that the problem is not with 
faulting, but with the observed object being invalidated (apparently). If 
faulting an observed object caused a crash, then I don't see how Core Data 
could work at all.

Similarly, keyPathsForValuesAffectingKey seems like a red herring. It uses 
observation internally (perhaps setting it up via a fast path not available to 
applications), so it doesn't really change the picture.

I think you will have to analyze the crash scenario more carefully. 
Essentially, you crashed in -[NMTopicNodeMO willTurnIntoFault], which I assume 
is one of your classes. What phase of the migration is this in -- is the object 
in the store being migrated from, or to? Does migration do something 
differently (such as forcibly invalidating objects) that doesn't happen in 
normal Core Data behavior, and therefore that your code doesn't expect or 
co-exist well with? Has the observation that's being removed at the time of 
the crash even been established, or is your willTurnIntoFault cause making an 
incorrect assumption about what happened earlier. Is it necessary, when an 
object turns into a fault during a migration, to just add a validation check 
that the observed object's ID is valid, before trying to remove the observation?

TBH, I think you're going to have to be more disciplined in your analysis, and 
investigate one question at a time, rather than trying a scattershot approach.

Note that, given the black-box nature of much Core Data behavior, it might not 
even be possible to formulate an answer about what's gone wrong. You may be 
better off submitting a bug report claiming that your app's reasonable behavior 
produces an unreasonable crash.

One final point, which I doubt has anything to do with your crash, but may 
possibly be relevant:

 [self addObserver:self forKeyPath:@toOne.attribute options:0 context:NULL];


NULL is a terrible choice for the context parameter. Use a value that's 
unique (some people use a globally unique string, I use the class object of the 
observer -- the considerations are a larger discussion) to the observer. This 
is a defect in the KVO mechanism, BTW.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Gideon King]

It's a graphical application, and when things change in the back end, I often 
need to move things around on the screen, so need to invalidate the drawing 
rect at the old location, perhaps remove some bezier paths, and then need to 
set it to need display at the new location. I was just thinking that it may be 
handy for situations like this where I may have a whole lot of different things 
that could happen in the back end, which all lead to the same action required 
at the front end (though I will probably still need to use something like a 
notification queue and coalescing to make sure that I only do the expensive 
calculations once for a bunch of related changes in the back end.


Gideon

On 10/08/2010, at 2:38 AM, Dave Fernandes wrote:

 
 On 2010-08-09, at 11:13 AM, Gideon King wrote:
 
 Dave's idea of using + (NSSet*)keyPathsForValuesAffectingKey may help in 
 some situations, but I don't think it's practical for all, especially where 
 I'm using KVO for my front end to observe changes in the back end and react, 
 where I sometimes need to know the before and after values. I'd have to 
 think about that some more...
 
 Actually, it's particularly effective for keeping the UI updated and works 
 with bindings. You provide an accessor method for your attribute and when 
 called, the method first checks toOne's attributes that it depends on and 
 then updates itself to be consistent before returning the new value. However, 
 if you want the 'before' value, you will need your own caching/messaging in 
 there somewhere. How is this information used?
 
 Dave

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Gideon King]

OK, it's well after 3am now, so I'll leave more detailed analysis until after 
some sleep.

The scenario is that of a simple Save As. As far as I am aware, I am not doing 
anything unusual in the process. I do not forcibly invalidate objects. It's a 
bit hard to track exactly what's happening, but I am able to look at the 
situation after willTurnIntoFault, and the observationInfo shows that the 
object at the destination of the to one relationship still has the key paths as 
registered by its parent established when it is made into a fault - i.e. I 
successfully established the observing at the parent level, which got 
automatically transferred to the child (without the first part of the key 
path), and then the child was faulted without the observing being 
removed...which is why I thought it might be some inconsistency with my model. 
I didn't establish that particular observation myself, so should not have to 
remove it myself.

I guess the topic did broaden from there to general issues around what is the 
right way to use KVO, as I have some other issues in my app related to it in 
other areas, and I'm looking for the recommended design patterns for KVO 
amongst core data entities, and between a core data backend and a gui 
controller front end.

I don't quite get why I should be passing in something for the context when 
setting up observing. I would have thought that that would be only for cases 
where either:
a) you actually want to use some context data
b) you have more than one key path the same and the observation object isn't 
enough information to give you the necessary context.
...neither of which is the case for my application.

Anyway, brain's fried...thanks for the help, and I'll check into it more in the 
morning...

Regards

Gideon

On 10/08/2010, at 2:57 AM, Quincey Morris wrote:

 
 But you haven't addressed Keary's excellent point that the problem is not 
 with faulting, but with the observed object being invalidated (apparently). 
 If faulting an observed object caused a crash, then I don't see how Core Data 
 could work at all.
 
 Similarly, keyPathsForValuesAffectingKey seems like a red herring. It uses 
 observation internally (perhaps setting it up via a fast path not available 
 to applications), so it doesn't really change the picture.
 
 I think you will have to analyze the crash scenario more carefully. 
 Essentially, you crashed in -[NMTopicNodeMO willTurnIntoFault], which I 
 assume is one of your classes. What phase of the migration is this in -- is 
 the object in the store being migrated from, or to? Does migration do 
 something differently (such as forcibly invalidating objects) that doesn't 
 happen in normal Core Data behavior, and therefore that your code doesn't 
 expect or co-exist well with? Has the observation that's being removed at 
 the time of the crash even been established, or is your willTurnIntoFault 
 cause making an incorrect assumption about what happened earlier. Is it 
 necessary, when an object turns into a fault during a migration, to just add 
 a validation check that the observed object's ID is valid, before trying to 
 remove the observation?
 
 TBH, I think you're going to have to be more disciplined in your analysis, 
 and investigate one question at a time, rather than trying a scattershot 
 approach.
 
 Note that, given the black-box nature of much Core Data behavior, it might 
 not even be possible to formulate an answer about what's gone wrong. You may 
 be better off submitting a bug report claiming that your app's reasonable 
 behavior produces an unreasonable crash.
 
 One final point, which I doubt has anything to do with your crash, but may 
 possibly be relevant:
 
 [self addObserver:self forKeyPath:@toOne.attribute options:0 context:NULL];
 
 
 NULL is a terrible choice for the context parameter. Use a value that's 
 unique (some people use a globally unique string, I use the class object of 
 the observer -- the considerations are a larger discussion) to the observer. 
 This is a defect in the KVO mechanism, BTW.

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Kyle Sluder]

On Mon, Aug 9, 2010 at 10:23 AM, Gideon King gid...@novamind.com wrote:
 I don't quite get why I should be passing in something for the context when 
 setting up observing. I would have thought that that would be only for cases 
 where either:
 a) you actually want to use some context data
 b) you have more than one key path the same and the observation object isn't 
 enough information to give you the necessary context.
 ...neither of which is the case for my application.

The context is the only unique identifier for your observation. If
both your implementation and your superclass's implementation register
for the same keypath on the same object, the context is the only way
to differentiate.

The only sane thing to do is the technique espoused by Mike Ash
http://www.mikeash.com/pyblog/key-value-observing-done-right.html,
OFBinding 
http://github.com/omnigroup/OmniGroup/blob/master/Frameworks/OmniFoundation/OFBinding.h,
and AppKit itself (all the various NS*Binder classes): create helper
objects for each individual binding, and have them use their self
pointers as the context arguments.

--Kyle Sluder
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Quincey Morris]

On Aug 9, 2010, at 10:42, Kyle Sluder wrote:

 On Mon, Aug 9, 2010 at 10:23 AM, Gideon King gid...@novamind.com wrote:
 I don't quite get why I should be passing in something for the context when 
 setting up observing. I would have thought that that would be only for cases 
 where either:
 a) you actually want to use some context data
 b) you have more than one key path the same and the observation object isn't 
 enough information to give you the necessary context.
 ...neither of which is the case for my application.
 
 The context is the only unique identifier for your observation. If
 both your implementation and your superclass's implementation register
 for the same keypath on the same object, the context is the only way
 to differentiate.
 
 The only sane thing to do is the technique espoused by Mike Ash
 http://www.mikeash.com/pyblog/key-value-observing-done-right.html,
 OFBinding 
 http://github.com/omnigroup/OmniGroup/blob/master/Frameworks/OmniFoundation/OFBinding.h,
 and AppKit itself (all the various NS*Binder classes): create helper
 objects for each individual binding, and have them use their self
 pointers as the context arguments.

In many cases, it's sufficient to pass any ol' unique object pointer (or unique 
non-object value, of course, but getting uniqueness via object pointers is 
easier). Many people use globally unique strings. I generally use the 
observer's class object. That's assuming, of course, that there's no real 
context information that you need to pass in.

To complete the sermon you started:

Given the unique context identifier, the 
'observeValueForKeyPath:ofObject:change:context:' *must* limit itself to 
handling invocations with the correct identifier and *must not* call the super 
implementation if it's correct. If the context is unrecognized, the method 
*must* call the super implementation instead. If Gideon didn't do that, then 
any number of application misbehaviors might result.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Dave Fernandes]

On 2010-08-09, at 12:57 PM, Quincey Morris wrote:

 On 10/08/2010, at 12:20 AM, Keary Suska wrote:
 
 
 The trace shows that the destination has been invalidated before your 
 object is faulted, and so the exception is raised when it tries to remove 
 observation. Invalidated object references should be rare--I would expect 
 Core Data to clean up relationships when a MOC is reset but that does not 
 appear to be the case (at least not all the time). Have you re-looked at 
 the issues around the question you asked back in 
 April:http://www.cocoabuilder.com/archive/cocoa/284398-invalidated-managed-objects.html
  ?
 
 But you haven't addressed Keary's excellent point that the problem is not 
 with faulting, but with the observed object being invalidated (apparently). 
 If faulting an observed object caused a crash, then I don't see how Core Data 
 could work at all.
 
 Similarly, keyPathsForValuesAffectingKey seems like a red herring. It uses 
 observation internally (perhaps setting it up via a fast path not available 
 to applications), so it doesn't really change the picture.

I have no idea how keyPathsForValuesAffectingKey works under the hood, but it 
automagically handles setting up and tearing down observers when a MOC is 
reset, released, etc. So these kinds of problems simply don't happen. It's 
really the easy way to do it (unless you have to support Tiger).

Dave___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Dave Fernandes]

Ah. OK. keyPathsForValuesAffectingKey wouldn't be directly helpful there. But 
KVO is easier to use with NS*Controller objects than directly with managed 
objects. Can you bind your view to one of the standard controllers instead, and 
have that controller track your managed object?

On 2010-08-09, at 1:03 PM, Gideon King wrote:

 It's a graphical application, and when things change in the back end, I often 
 need to move things around on the screen, so need to invalidate the drawing 
 rect at the old location, perhaps remove some bezier paths, and then need to 
 set it to need display at the new location. I was just thinking that it may 
 be handy for situations like this where I may have a whole lot of different 
 things that could happen in the back end, which all lead to the same action 
 required at the front end (though I will probably still need to use something 
 like a notification queue and coalescing to make sure that I only do the 
 expensive calculations once for a bunch of related changes in the back end.
 
 
 Gideon
 
 On 10/08/2010, at 2:38 AM, Dave Fernandes wrote:
 
 
 On 2010-08-09, at 11:13 AM, Gideon King wrote:
 
 Dave's idea of using + (NSSet*)keyPathsForValuesAffectingKey may help in 
 some situations, but I don't think it's practical for all, especially where 
 I'm using KVO for my front end to observe changes in the back end and 
 react, where I sometimes need to know the before and after values. I'd have 
 to think about that some more...
 
 Actually, it's particularly effective for keeping the UI updated and works 
 with bindings. You provide an accessor method for your attribute and when 
 called, the method first checks toOne's attributes that it depends on and 
 then updates itself to be consistent before returning the new value. 
 However, if you want the 'before' value, you will need your own 
 caching/messaging in there somewhere. How is this information used?
 
 Dave
 

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

re: KVO and Core data

[Ben Trumbull]

 Hi all,
 
 I have a KVO registration like this:
 
 [self addObserver:self forKeyPath:@toOne.attribute options:0 context:NULL];
 
 I establish this on -awakeFromInsert or -awakeFromFetch, and have the 
 corresponding removeObserver called on -willTurnIntoFault.
 
 The problem is that when I do a Save As on my document, it migrates the 
 persistent store, which appears to cause the object at the destination of the 
 toOne relationship to be turned into a fault before the object that 
 registered as an observer is. Now when I check the observationInfo for the 
 object that is being faulted (at the end of the toOne relationship), it has 
 itself registered as an observer for attribute. 
 
 I guess this means that behind the scenes, the KVO establishes observation 
 information automatically at every level of a key path (something I hadn't 
 realized before, but which appears to make sense). 
 
 Then something behind the scenes tries to access the attribute on an object 
 that has been turned into a fault, and invalidated, and everything comes 
 crashing down.
 
 So I have two questions:
 
 1. Is it the right way for me to be adding observation on the awake methods 
 and removing it on willTurnToFault?
 
 2. If this is OK, then what could be affecting the system such that it 
 doesn't remove the observation information in the destination of the to-one 
 relationship? I'm wondering if there could be something in my data model that 
 could be affecting it. This relationship is modeled as a one to one, with a 
 delete rule of cascade from the parent to the child, and the inverse 
 relationship is also modeled, with a deny rule. There's also another optional 
 relationship from the child to the parent with a deny rule, modeled in one 
 direction only (and not used in the data I am testing with anyway).

Your problem here is this MOC is being torn down, and the toOne managed 
object is already toast.  So it's not possible to get its attribute.  KVO 
isn't really in a position to deal with this.

Probably the best solution is for the toOne object to traverse the inverse and 
tell it's parent when to add or remove the KVO observation.  So this way when 
attribute is nuked, parent stops observing it.

Another possibility is to just have the accessor methods on toOne for the 
setter for attribute traverse the inverse manually and inform the parent 
outside of KVO.

- Ben



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and Core data

[Gideon King]

Thanks for all the feedback guys. I really need to rethink how I use KVO 
throughout my application.

I've read Mike Ash's post, and see the issues there - I'm surprised there 
aren't more places where the standard observations are tripping over each other.

Time for some refactoring...

Gideon___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO question

[Sean McBride]

On Thu, 1 Jul 2010 10:30:39 -0700, Rainer Standke said:

I have a core data app where I don't necessarily know when managed
objects go away, as in: become faults, will be deleted etc..

You know they become faults when willTurnIntoFault is invoked.  You'll
know they'll be deleted when prepareForDeletion is invoked.

 I also need
to add the observer to the managed object in awakeFromFetch, but that
gets not only called upon opening an existing object, but also later on
when fetches are executed.

Tell us more about what you're doing.  Who's observing who?  When?  Why?

--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO question

[Kyle Sluder]

On Jul 1, 2010, at 8:26 AM, Rainer Standke li...@standke.com wrote:

 Hello all,
 
 is it possible to determine if one object is observing another? Specifically, 
 I'd like one object to ask another are you observing me?. That way I could 
 determine if I need to remove that observer before I let go of the observed 
 object...

This is a very good indication that you have an inverted or cyclical 
dependency. Your observee shouldn't need to know about your observers.

What is your specific setup?

--Kyle Sluder___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO question

[Rainer Standke]

I have a core data app where I don't necessarily know when managed objects go 
away, as in: become faults, will be deleted etc.. I also need to add the 
observer to the managed object in awakeFromFetch, but that gets not only called 
upon opening an existing object, but also later on when fetches are executed.

I take it the answer to my question is no? As in: No, an object can not ask 
another if it's being observe by it?

For now I have solved the problem by setting a flag on the managed object when 
it registers itself for observation. 

Rainer


On Jul 1, 2010, at 9:15 , Kyle Sluder wrote:

 On Jul 1, 2010, at 8:26 AM, Rainer Standke li...@standke.com wrote:
 
 Hello all,
 
 is it possible to determine if one object is observing another? 
 Specifically, I'd like one object to ask another are you observing me?. 
 That way I could determine if I need to remove that observer before I let go 
 of the observed object...
 
 This is a very good indication that you have an inverted or cyclical 
 dependency. Your observee shouldn't need to know about your observers.
 
 What is your specific setup?
 
 --Kyle Sluder

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO question

[Matt Neuburg]

On Thu, 1 Jul 2010 08:26:00 -0700, Rainer Standke li...@standke.com said:
Hello all,

is it possible to determine if one object is observing another?

observationInfo doesn't do this?

m.

-- 
matt neuburg, phd = m...@tidbits.com, http://www.tidbits.com/matt/
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
http://www.tidbits.com/matt/default.html#applescriptthings



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO question

[Keary Suska]

On Jul 1, 2010, at 11:30 AM, Rainer Standke wrote:

 I have a core data app where I don't necessarily know when managed objects go 
 away, as in: become faults, will be deleted etc.. I also need to add the 
 observer to the managed object in awakeFromFetch, but that gets not only 
 called upon opening an existing object, but also later on when fetches are 
 executed.
 
 I take it the answer to my question is no? As in: No, an object can not ask 
 another if it's being observe by it?

Specifically, no, because an object is completely ignorant of what it is 
observing, except when specifically implemented otherwise. The observed object 
*does* know what objects have registered with it, but the data structure is 
opaque and undocumented, and subject to change (AFAIK).

 For now I have solved the problem by setting a flag on the managed object 
 when it registers itself for observation. 
 
 Rainer
 
 
 On Jul 1, 2010, at 9:15 , Kyle Sluder wrote:
 
 On Jul 1, 2010, at 8:26 AM, Rainer Standke li...@standke.com wrote:
 
 Hello all,
 
 is it possible to determine if one object is observing another? 
 Specifically, I'd like one object to ask another are you observing me?. 
 That way I could determine if I need to remove that observer before I let 
 go of the observed object...
 
 This is a very good indication that you have an inverted or cyclical 
 dependency. Your observee shouldn't need to know about your observers.
 
 What is your specific setup?
 
 --Kyle Sluder


Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO oddity (or am I *really* idiot ?)

[Kyle Sluder]

On Jun 9, 2010, at 7:05 AM, vincent habchi vi...@macports.org wrote:

 Hi there,
 no latin this time, I swear! :)
 
 Well, please tell me I am a fool: when I execute those two lines:
 
NSLog(@%@, [[NSApp delegate] appController]);
NSLog(@%@, [NSApp valueForKey:@delegate.appController]);

@delegate.appController is a keypath, not a key.

--Kyle Sluder
(Sent from WWDC)
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO oddity (or am I *really* idiot ?)

[Graham Cox]

On 10/06/2010, at 12:05 AM, vincent habchi wrote:

 2010-06-09 15:52:57.526 PostSIG[5503:a0b] [NSApplication 0x1003264d0 
 valueForUndefinedKey:]: this class is not key value coding-compliant for the 
 key delegate.appController.
 
 [NSApp valueForKey:@delegate] works all right.
 appController is a synthesized readonly property of the delegate.
 
 What did I miss? 


delegate.appController is not a key, it's a key PATH. Use it with 
-valueForKeyPath:

--Graham


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO oddity (or am I *really* idiot ?)

[vincent habchi]

Le 9 juin 2010 à 16:10, Graham Cox a écrit :

 
 On 10/06/2010, at 12:05 AM, vincent habchi wrote:
 
 2010-06-09 15:52:57.526 PostSIG[5503:a0b] [NSApplication 0x1003264d0 
 valueForUndefinedKey:]: this class is not key value coding-compliant for the 
 key delegate.appController.
 
 [NSApp valueForKey:@delegate] works all right.
 appController is a synthesized readonly property of the delegate.
 
 What did I miss? 
 
 
 delegate.appController is not a key, it's a key PATH. Use it with 
 -valueForKeyPath:

Thanks to both. You see, I am *really* a moron (and sometimes even an oxymoron, 
which is worse! :)).___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO oddity (or am I *really* idiot ?)

[vincent habchi]

Le 9 juin 2010 à 16:10, Kyle Sluder a écrit :

 @delegate.appController is a keypath, not a key.

Thanks Kyle. As I said (privately) to Graham, I am even better than a moron: an 
oxymoron.
Cheers and forgive my stupidity. Enjoy WWDC!

Vincent___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO oddity (or am I *really* idiot ?)

[Joanna Carter]

Hi Vincent

 Thanks Kyle. As I said (privately) to Graham...

No you didn't. I got that message with the list in the CC field. :-)

Joanna

--
Joanna Carter
Carter Consulting

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and object release timing (for a NSCollectionView)

[vincent habchi]

Hi Corbin,

 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 the program crash,
 
 If you have a crash, 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 released. Instead, 
there is an implied CAAnimation (or something similar) that makes 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.

The (very dirty) workaround is this: instead of immediately release the 
represented object, retain it, target it for delayed deletion, and then remove 
it from the array; the real deletion is triggered in the dealloc routine of the 
corresponding NSView (or subclass thereof) :

// Highly heterodox
- (void)dealloc {
[super dealloc];
NSApp delegate] appController] layerManager] removeTargetedCALayer];
}

I had to write it this way, instead of the more orthodox :

- (void)dealloc {
NSApp delegate] appController] layerManager] removeTargetedCALayer];
[super dealloc];
}

because the KVO removal takes place in the [super dealloc] routine…

Great WE,
Vincent___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and object release timing (for a NSCollectionView)

[Kyle Sluder]

On Sat, Jan 23, 2010 at 1:48 AM, vincent habchi vi...@macports.org wrote:
 The problem is that when the represented object is removed from the array 
 controller, the corresponding NSView is not immediately released. Instead, 
 there is an implied CAAnimation (or something similar) that makes 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 in any non-trivial context. You might want to have
some sort of notification or delegate method that keeps your object
alive long enough. Putting code after calling [super dealloc] is
usually a bad idea, because self will be a garbage pointer, and how
many of us are so careful about pointer lifetimes that we're immune to
writing use-after-free bugs, especially when we return to the code six
months later?

--Kyle Sluder
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO and object release timing (for a NSCollectionView)

[Corbin Dunn]

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 the program crash,

If you have a crash, it is always best to post the crash report.

--corbin


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO cross dependencies

[Roland King]

One option - use Garbage Collection under Snow Leopard, it does it all for you. 

If you can't do that. I assume, from the fact that your observed objects are 
being released at all that the observing objects are not retaining them (or 
keeping strong references if you are using Garbage Collection), if you had them 
retained by the observing object then they wouldn't be getting dealloced. If 
the observations are in a tree, then you could have the observers retain the 
objects they are observing and unobserve them as they release them, then you'll 
never have the issue of an object with registered observers being deallocated. 

If, however you can't do that, because the objects all observe each other, 
you'll get retain cycles (again assuming you are not using GC), so you cannot 
retain and need to tell the observing object to remove its observations on the 
observed object before it dies. One way to do that is to have another property 
on the objects, something like canBeObserved, and have all your observers 
observe that property *as well* as other observations they have. In your 
dealloc method, right at the start of it, flip that property to NO and all your 
observers will be told you are no longer observable, they are then responsible 
for removing their observations. This happens synchronously, so by the time you 
continue with dealloc, nobody is observing you any more. 

We had a thread about this a few months ago where we discussed whether it was 
legitimate to do this in dealloc and discussing a note in the Snow Leopard 
release notes about that message and I believe that most people were satisfied 
that it was a supported thing to do. Note that even if you do this, under 10.5 
you will STILL get that warning message (not an exception) because it was 
emitted at the start of dealloc() before you had a chance to tell your 
observers to stop observing, that was what the release note addressed. 

I don't think there is a documented way of finding out who is observing you and 
what they are observing. 



On 13-Nov-2009, at 9:43 PM, Half Activist wrote:

 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 way, order I 
 deallocate the objects that will always happen because of these cross 
 observations. Therefore what I should do is tell everyone that's observing an 
 object to remove them as observers. But how can I get a list of all observed 
 keys and the observers?
 
 Regards.
 
 PS: I thought about setting the observation info to nil but I guess this is a 
 one way ticket to a segfault.
 
 ___
 
 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:
 http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
 
 This email sent to r...@rols.org

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com