Re: observeValueForKeyPath:... called too often in macOS 12

[Gerriet M. Denkmann]

> On 19 Oct 2016, at 15:08, Quincey Morris 
>  wrote:
> 
> On Oct 19, 2016, at 00:49 , Gerriet M. Denkmann  wrote:
>> 
>> Before:
>> 
>> TextField1 bound Value to:
>>  Shared User Defaults Controller
>>  Controller Key = values
>>  Model Key Path = TextField1
>> 
>> This worked fine.
> 
> Yeah, I didn’t realize you were binding to a NSUserDefaultsController. Since 
> that implements NSEditorRegistration and NSEditor, switching to 
> NSObjectController doesn’t improve anything.
> 
> The real problem is that it just doesn’t know when you app is about to quit. 
> If you want to save text fields that are still being edited, make sure you 
> invoke one of the NSEditor methods on the NSUserDefaultsController before you 
> quit, e.g. “commitEditing”. That will force it to end editing.

I added:
applicationWillTerminate:
[ NSUserDefaultsController.sharedUserDefaultsController 
commitEditing ] 
which seems to fix this issue (which was clearly a bug in my own code).

Thanks for your help!


Kind regards,

Gerriet.


___

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: observeValueForKeyPath:... called too often in macOS 12

[Quincey Morris]

On Oct 19, 2016, at 00:49 , Gerriet M. Denkmann  wrote:
> 
> Before:
> 
> TextField1 bound Value to:
>   Shared User Defaults Controller
>   Controller Key = values
>   Model Key Path = TextField1
> 
> This worked fine.

Yeah, I didn’t realize you were binding to a NSUserDefaultsController. Since 
that implements NSEditorRegistration and NSEditor, switching to 
NSObjectController doesn’t improve anything.

The real problem is that it just doesn’t know when you app is about to quit. If 
you want to save text fields that are still being edited, make sure you invoke 
one of the NSEditor methods on the NSUserDefaultsController before you quit, 
e.g. “commitEditing”. That will force it to end editing.

However, you will have to consider related issues such as Sudden App 
Termination and Automatic App Termination. There are mechanism to suppress 
these, if your app is using them, while there are “unsaved changes”, but since 
your AppDelegate doesn’t implement the NSEditor protocols, there may be 
something you need to do manually, if the NSUserDefaultsController doesn’t do 
the right thing automatically.

___

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: observeValueForKeyPath:... called too often in macOS 12

[Quincey Morris]

Oo! I see! Here’s the main problem:

> On Oct 14, 2016, at 23:08 , Gerriet M. Denkmann  wrote:
> 
> My app (macOS 12) observes a value in NSUserDefaults.

Well, no, it doesn’t. It observes a value in a NSUserDefaultsController.values. 
That’s a different kettle of wax.

First of all, any NSController subclass defines a mediating controller, aka a 
glue object, aka a piece of junk black box. NSUserDefaultsController exists in 
particular to provide a way of binding UI elements directly to NSUserDefaults 
*without programmatic involvement*. As far as I’m concerned, any programmatic 
use of a NSController class is a code smell (although there are certainly a few 
things where the programmatic need is greater than the smell).

However, NSController subclasses do what they do, however they want to do it. 
The “new” 10.12 behavior you’re seeing may be a bug, or it may be a change to 
the implementation that doesn’t care about poorer performance, or … . See above 
under “piece of junk” and “black box”.

NSUserDefaultsController.values *is* documented to be KVO compliant, and you 
*can* observe its values, but there’s no API contract that says you’re going to 
be happy about what exactly happens.

Some comments about particular issues:

> Bug1: no NSKeyValueObservingOptionOld. Should have old value, but just has 
> NSNull

I think all NSController subclasses have this flaw.

> Bug2: called at start (after applicationDidFinishLaunching) - although 
> nothing has changed yet

The user defaults haven’t changed, but the internal binding[-equivalent] 
between NSUserDefaultsController and NSUserDefaults has to be set up, and that 
*is* a change to the values as held by the NSUserDefaultsController. If this is 
different from 10.11, it may actually be a bug fix.

> Bug3: any change is observed twice

Looking at the stack trace, the first notification occurs when the text field 
reports its new value across its binding to the NSUserDefaultsController. The 
second occurs sometime later. I suspect that’s because the change to the 
NSUserDefaults value flows back across the NSUserDefaultsController binding. 
This may be a bug, or it may be a result of some part of the NSUserDefaults 
happening asynchronous now. AFAIK, there’s no clear contract about values going 
around in circles across bindings. See above under “piece of junk” and “black 
box”.

> Bug4: changes not keep on quit
> Check:change a TextField; do not use CR or leave the TextField; quit 
> the app. Start it again.
>   Maybe this is the way it should be. But in the age of autoSave 
> it feels a bit strange though.

We’re treating this as not a bug in observations.

> Bug5: changing a TextField to empty string reverts to registrationDefaults 
> for this TextField.
> Check:start app; set both TextFields to other than 
> registrationDefaults; quit.
>   start app again; select any TextField; hit "delete", then CR or 
> tab to other TextField →
>   empty string will be replaced by the registrationDefault.
>   
>   This happens only once per TextField. Replacing the 
> registrationDefault again with an empty
>   string just keeps this empty string.
>   At the next start of the app, the empty string will again be 
> replaced by the registrationDefault.
>   
>   Maybe this is the way it should be: empty string → nil and nil 
> → registrationDefault.
>   Feels a bit strange though.

I think this is a consequence of using a binding or of using a NSController 
subclass. One of those mechanisms, I guess, changes the empty string to nil, 
being unaware that that’s going to trigger the reversion to registration 
defaults. It’s probably doing the right thing according to some set of rules, 
just not the rules you want.

> Bug6: sometimes the first change in any TextField reverts to 
> registrationDefaults for both TextFields
> Check:not reproducible. Just happens when it feels like it: sometimes 
> bug a few times in a row,
>   sometimes no bug half a dozen times.

I dunno, I didn’t get as far as looking into this.

My advice is: don’t use NSUserDefaultsController for this. (Don’t use 
NSUserDefaultsController except for binding UI elements directly without the 
involvement of code.) Unfortunately NSUserDefaults isn’t documented as KVO 
compliant for user-defined keys, although it may actually be.

The way I handle this is that I create a custom class for preferences, which is 
fully KVO compliant for its custom properties, and I bind to or observe this 
object. Internally, the preferences object updates and/or reads the 
NSUserDefaults values. This is actually a useful level of abstraction, because 
often what you would like to store is not quite in the same form as what you 
would like to display. At the same time, it tends to be a lot of glue code.

There’s probably more to discuss, but 

Re: observeValueForKeyPath:... called too often in macOS 12

[Gerriet M. Denkmann]

> On 19 Oct 2016, at 13:01, Quincey Morris 
>  wrote:
> 
> 
> One way around this is to use a NSObjectController bound between the text 
> field and the data model (user defaults in this case). NSObjectController 
> implements the editor protocols, so this covers the case where the window 
> closes while an edit is in progress. However, IIRC it doesn’t help when a 
> document “save” occurs or when the app quits, for separate reasons.

I am struggling to do so (and failing miserably):

Before:

TextField1 bound Value to:
Shared User Defaults Controller
Controller Key = values
Model Key Path = TextField1

This worked fine.

Now added NSObjectController
Mode = Class
Class Name = NSMutableDictionary ??
not prepares Content
editable

Bind Controller Content to:
Shared User Defaults Controller
Controller Key = values
Model Key Path = standardUserDefaults ??

TextField1 bound Value to:
Object Controller
Controller Key = selection
Model Key Path = TextField1 ??

This crashes with -[_NSControllerObjectProxy copyWithZone:]: unrecognized 
selector sent to instance 0x10….

Obviously I am not knowing what to do and am just groping blindly.

How does one put an NSObjectController between an NSTextField and the Shared 
User Defaults Controller ?

Gerriet.


___

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

[NSEditorRegistration sidetrack] observeValueForKeyPath:... called too often in macOS 12

[Michael Starke]

> On 19 Oct 2016, at 08:01, Quincey Morris 
>  wrote:
> 
> On Oct 18, 2016, at 22:33 , Gerriet M. Denkmann  wrote:
>> 
>> I have just done this (can send it to you if you are interested).
> 
> I’d be interested at looking at it, if you can email it to me.
> 
>> Bug4:changes not keep on quit
>> Check:   change a TextField; do not use CR or leave the TextField; quit 
>> the app. Start it again.
>>  Maybe this is the way it should be. But in the age of autoSave 
>> it feels a bit strange though.
> 
> I’m pretty sure this is nothing to do with KVO or user defaults.
> 
> An edited text field won’t get “committed” back to the data model until you 
> end editing (Tab or Return) unless you arrange for it to happen. There’s are 
> two *informal* protocols (NSEditor and NSEditorRegistration) that bridge 
> between editors and controllers. Both NSDocument and NSViewController 
> implement both of these, but that would only work if the view controller 
> registered itself with the document, but it doesn’t. In effect the 
> NSWindowController intervenes between the document and view controller, but 
> it *doesn’t* implement those protocols, so it breaks the chain.
> 
> One way around this is to use a NSObjectController bound between the text 
> field and the data model (user defaults in this case). NSObjectController 
> implements the editor protocols, so this covers the case where the window 
> closes while an edit is in progress. However, IIRC it doesn’t help when a 
> document “save” occurs or when the app quits, for separate reasons.

I've had to deal with the issue of lost data on save/autosave recently and came 
up with the following solutions:

Solution A: bind the text field's value directly to a property of the 
NSDocument so it is the model controller, the text editor get's registered and 
NSDocument commits changes on active editors before saving as documented in 
NSDocument.h

Solution B: bind the text field's value to a custom NSController and vent the 
NSEditorRegistration calls up to NSDocument.

Both of these work, but you have to keep track of other instances where you 
bind to objects, that do not implement NSEditorRegistration, e.g. I used 
objectValue for NSViews in a NSTableViews to bind values. This required a 
custom NSViews to get editors registered in NSDocument.

> Anyway, my point is that I think this is an unrelated problem.


___m i c h a e l   s t a r k e 
   geschäftsführer
   HicknHack Software GmbH
   www.hicknhack-software.com
   
___k o n t a k t
   +49 (170) 3686136
   cont...@hicknhack.com
   
___H i c k n H a c k   S o f t w a r e   G m b H
   geschäftsführer - maik lathan | andreas reischuck | michael starke
   bayreuther straße 32
   01187 dresden
   amtsgericht dresden HRB 30351
   sitz - dresden


___

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: observeValueForKeyPath:... called too often in macOS 12

[Gerriet M. Denkmann]

> On 19 Oct 2016, at 13:01, Quincey Morris 
>  wrote:
> 
> On Oct 18, 2016, at 22:33 , Gerriet M. Denkmann  wrote:
>> 
>> I have just done this (can send it to you if you are interested).
> 
> I’d be interested at looking at it, if you can email it to me.
Already sent by separate mail.

> 
>> Bug4:changes not keep on quit
>> Check:   change a TextField; do not use CR or leave the TextField; quit 
>> the app. Start it again.
>>  Maybe this is the way it should be. But in the age of autoSave 
>> it feels a bit strange though.
> 
> I’m pretty sure this is nothing to do with KVO or user defaults.
> 
> An edited text field won’t get “committed” back to the data model until you 
> end editing (Tab or Return) unless you arrange for it to happen. There’s are 
> two *informal* protocols (NSEditor and NSEditorRegistration) that bridge 
> between editors and controllers. Both NSDocument and NSViewController 
> implement both of these, but that would only work if the view controller 
> registered itself with the document, but it doesn’t. In effect the 
> NSWindowController intervenes between the document and view controller, but 
> it *doesn’t* implement those protocols, so it breaks the chain.
> 
> One way around this is to use a NSObjectController bound between the text 
> field and the data model (user defaults in this case). NSObjectController 
> implements the editor protocols, so this covers the case where the window 
> closes while an edit is in progress. However, IIRC it doesn’t help when a 
> document “save” occurs or when the app quits, for separate reasons.
> 
> Anyway, my point is that I think this is an unrelated problem.

I am quite sure you are right. I will try to use an NSObjectController. 
Probably should have done so in the first place.


Kind regards,

Gerriet.


___

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: observeValueForKeyPath:... called too often in macOS 12

[Quincey Morris]

On Oct 18, 2016, at 22:33 , Gerriet M. Denkmann  wrote:
> 
> I have just done this (can send it to you if you are interested).

I’d be interested at looking at it, if you can email it to me.

> Bug4: changes not keep on quit
> Check:change a TextField; do not use CR or leave the TextField; quit 
> the app. Start it again.
>   Maybe this is the way it should be. But in the age of autoSave 
> it feels a bit strange though.

I’m pretty sure this is nothing to do with KVO or user defaults.

An edited text field won’t get “committed” back to the data model until you end 
editing (Tab or Return) unless you arrange for it to happen. There’s are two 
*informal* protocols (NSEditor and NSEditorRegistration) that bridge between 
editors and controllers. Both NSDocument and NSViewController implement both of 
these, but that would only work if the view controller registered itself with 
the document, but it doesn’t. In effect the NSWindowController intervenes 
between the document and view controller, but it *doesn’t* implement those 
protocols, so it breaks the chain.

One way around this is to use a NSObjectController bound between the text field 
and the data model (user defaults in this case). NSObjectController implements 
the editor protocols, so this covers the case where the window closes while an 
edit is in progress. However, IIRC it doesn’t help when a document “save” 
occurs or when the app quits, for separate reasons.

Anyway, my point is that I think this is an unrelated problem.

___

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: observeValueForKeyPath:... called too often in macOS 12

[Gerriet M. Denkmann]

> On 19 Oct 2016, at 11:43,Jerome Krinock  wrote:
> 
> 
>> On 2016 Oct 18, at 19:32, Gerriet M. Denkmann  wrote:
>> 
>> 
>>> On 19 Oct 2016, at 02:00,Jerome Krinock :
>>> 
 On 2016 Oct 14, at 23:08, Gerriet M. Denkmann  wrote:
>>> 
 Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just 
 return NSNull instead of old or new values.
>>> 
>>> That only happens during that first spurious call, when the observer is 
>>> added.
>> 
>> Happens for me all the time. Never seen anything other than NSNull.
> 
> Well, then there is something weird in your app, or in mine.  I would bet on 
> yours, because if such change notifications were broken in 10.12, thousands 
> of apps would not work.  Create a small demo project and try to reproduce.

I have just done this (can send it to you if you are interested).
Messing around with this test app I found a few bugs (or to be cautious: a few 
things I did not expect):

Bug1:   no NSKeyValueObservingOptionOld. Should have old value, but just has 
NSNull

Bug2:   called at start (after applicationDidFinishLaunching) - although 
nothing has changed yet

Bug3:   any change is observed twice

Bug4:   changes not keep on quit
Check:  change a TextField; do not use CR or leave the TextField; quit the app. 
Start it again.
Maybe this is the way it should be. But in the age of autoSave 
it feels a bit strange though.

Bug5:   changing a TextField to empty string reverts to registrationDefaults 
for this TextField.
Check:  start app; set both TextFields to other than registrationDefaults; quit.
start app again; select any TextField; hit "delete", then CR or 
tab to other TextField →
empty string will be replaced by the registrationDefault.

This happens only once per TextField. Replacing the 
registrationDefault again with an empty
string just keeps this empty string.
At the next start of the app, the empty string will again be 
replaced by the registrationDefault.

Maybe this is the way it should be: empty string → nil and nil 
→ registrationDefault.
Feels a bit strange though.

Bug6:   sometimes the first change in any TextField reverts to 
registrationDefaults for both TextFields
Check:  not reproducible. Just happens when it feels like it: sometimes bug a 
few times in a row,
sometimes no bug half a dozen times.

Here I finally caught the bug:

start app, the two textfields are “a3" resp. "b3":

12:04:58.755044  +[AppDelegate initialize] registerDefaults {
12:04:58.894584  -[AppDelegate field1:] "a3"
12:04:58.901718  -[AppDelegate applicationDidFinishLaunching:] Done
12:04:59.056890  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaultsController.values.TextField2 = "b3";
12:04:59.057120  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaults.TextField2 = "b3"
12:04:59.057336  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaultsController.values.TextField1 = "a3";
12:04:59.057365  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaults.TextField1 = "a3"

changing field2 to "b4":

12:05:03.028507  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaultsController.values.TextField2 = "text2";
12:05:03.028605  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaults.TextField2 = "text2"
12:05:03.030307  -[AppDelegate field2:] "b4"
12:05:03.049222  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaultsController.values.TextField2 = "text2";
12:05:03.049275  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaults.TextField2 = "text2"
12:05:03.049579  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaultsController.values.TextField1 = "text1";
12:05:03.049600  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaults.TextField1 = "text1"



>> Current work-around: just ignore every second notification (i.e. ginore 1., 
>> 3rd, 5th etc.).
>> Not a very good solution, rather bound to break sooner or later. But okay 
>> for the time being.
> 
> “Not a very good solution”, indeed.  If I understand you correctly, if you 
> ran your app in 10.11 with this “solution”, it wouldn’t work.  
Highly probable that it won’t work.

> The workaround that I suggested …
But your workaround is based on the observation that the change dictionary has 
different content in different situations - which is something I never see here.


Kind regards,

Gerriet.


___

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

Re: observeValueForKeyPath:... called too often in macOS 12

[Gerriet M. Denkmann]

> On 19 Oct 2016, at 09:55, Gary L. Wade  wrote:
> 
> I have a thought.  Do you have a binding somewhere on a property in 
> NSUserDefaults?  

I just made a small test app: not document based, two TextFields bound to User 
Defaults Controller at values.TextField1, resp. …2.
Both observed via addObserver:forKeyPath:…

> Maybe your document is getting synchronised to iCloud and/or getting 
> autosaved very often?  

As far as I know, I am not using iCloud at all. Neither using auto save or 
anything.

If you (or anyone else) are interested, I can send you the test app project.

Kind regards,

Gerriet.


> These are things I’ve seen that can cause uncharacteristically often updates.
> --
> Gary L. Wade
> http://www.garywade.com/
> 
>> On Oct 18, 2016, at 7:32 PM, Gerriet M. Denkmann  wrote:
>> 
>> 
>>> On 19 Oct 2016, at 02:00,Jerome Krinock :
>>> 
 On 2016 Oct 14, at 23:08, Gerriet M. Denkmann  wrote:
 
 My app (macOS 12) observes a value in NSUserDefaults.  Starting with macOS 
 12 observeValueForKeyPath:… is called at the start of the program, 
 although nothing has changed yet.  When the value actually changes, it is 
 called twice.
>>> 
>>> I just added some code to one of my apps, to test this.  It confirmed your 
>>> observations, although I only tested in 10.12.
>>> 
 Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just 
 return NSNull instead of old or new values.
>>> 
>>> That only happens during that first spurious call, when the observer is 
>>> added.
>> 
>> Happens for me all the time. Never seen anything other than NSNull.
>> 
>> Current work-around: just ignore every second notification (i.e. ginore 1., 
>> 3rd, 5th etc.).
>> Not a very good solution, rather bound to break sooner or later. But okay 
>> for the time being.
>> 
>>> 
 If indeed this behavior is new in 10.12, it certainly warrants a Bug 
 Report.
>> 
>> Ok, will do so.
>> 
>> Kind regards,
>> 
>> Gerriet.
> 


___

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: observeValueForKeyPath:... called too often in macOS 12

[Jerome Krinock]

> On 2016 Oct 18, at 19:32, Gerriet M. Denkmann  wrote:
> 
> 
>> On 19 Oct 2016, at 02:00,Jerome Krinock :
>> 
>>> On 2016 Oct 14, at 23:08, Gerriet M. Denkmann  wrote:
>> 
>>> Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just 
>>> return NSNull instead of old or new values.
>> 
>> That only happens during that first spurious call, when the observer is 
>> added.
> 
> Happens for me all the time. Never seen anything other than NSNull.

Well, then there is something weird in your app, or in mine.  I would bet on 
yours, because if such change notifications were broken in 10.12, thousands of 
apps would not work.  Create a small demo project and try to reproduce.

> Current work-around: just ignore every second notification (i.e. ginore 1., 
> 3rd, 5th etc.).
> Not a very good solution, rather bound to break sooner or later. But okay for 
> the time being.

“Not a very good solution”, indeed.  If I understand you correctly, if you ran 
your app in 10.11 with this “solution”, it wouldn’t work.  The workaround that 
I suggested (filtering for substantive changes), you know, at least it has a 
logical basis, and if Apple changes this undocument behavior back to the old 
undocumented behavior, it should still 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: observeValueForKeyPath:... called too often in macOS 12

[Gary L. Wade]

I have a thought.  Do you have a binding somewhere on a property in 
NSUserDefaults?  Maybe your document is getting synchronized to iCloud and/or 
getting autosaved very often?  These are things I’ve seen that can cause 
uncharacteristically often updates.
--
Gary L. Wade
http://www.garywade.com/ 
> On Oct 18, 2016, at 7:32 PM, Gerriet M. Denkmann  wrote:
> 
> 
>> On 19 Oct 2016, at 02:00,Jerome Krinock :
>> 
>>> On 2016 Oct 14, at 23:08, Gerriet M. Denkmann  wrote:
>>> 
>>> My app (macOS 12) observes a value in NSUserDefaults.  Starting with macOS 
>>> 12 observeValueForKeyPath:… is called at the start of the program, although 
>>> nothing has changed yet.  When the value actually changes, it is called 
>>> twice.
>> 
>> I just added some code to one of my apps, to test this.  It confirmed your 
>> observations, although I only tested in 10.12.
>> 
>>> Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just 
>>> return NSNull instead of old or new values.
>> 
>> That only happens during that first spurious call, when the observer is 
>> added.
> 
> Happens for me all the time. Never seen anything other than NSNull.
> 
> Current work-around: just ignore every second notification (i.e. ginore 1., 
> 3rd, 5th etc.).
> Not a very good solution, rather bound to break sooner or later. But okay for 
> the time being.
> 
>> 
>>> If indeed this behavior is new in 10.12, it certainly warrants a Bug Report.
> 
> Ok, will do so.
> 
> Kind regards,
> 
> Gerriet.

___

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: observeValueForKeyPath:... called too often in macOS 12

[Gerriet M. Denkmann]

> On 19 Oct 2016, at 02:00,Jerome Krinock :
> 
>> On 2016 Oct 14, at 23:08, Gerriet M. Denkmann  wrote:
>> 
>> My app (macOS 12) observes a value in NSUserDefaults.  Starting with macOS 
>> 12 observeValueForKeyPath:… is called at the start of the program, although 
>> nothing has changed yet.  When the value actually changes, it is called 
>> twice.
> 
> I just added some code to one of my apps, to test this.  It confirmed your 
> observations, although I only tested in 10.12.
> 
>> Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just 
>> return NSNull instead of old or new values.
> 
> That only happens during that first spurious call, when the observer is added.

Happens for me all the time. Never seen anything other than NSNull.

Current work-around: just ignore every second notification (i.e. ginore 1., 
3rd, 5th etc.).
Not a very good solution, rather bound to break sooner or later. But okay for 
the time being.

> 
>>  If indeed this behavior is new in 10.12, it certainly warrants a Bug Report.

Ok, will do so.

Kind regards,

Gerriet.


___

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: observeValueForKeyPath:... called too often in macOS 12

[Graham Cox]

> On 15 Oct 2016, at 5:08 PM, Gerriet M. Denkmann  wrote:
> 
> Any workaround for these multiple (and unnecessary) calls?


Do they actually cause any problems? If not, just move on - there’s probably no 
point worrying about it. If they do cause a problem, then that might indicate a 
code smell of your own. I wouldn’t base any critical code on the exact 
behaviour of a KVO notification. They’re mostly just there to update UI (and in 
that case even double KVO notifications shouldn’t cause double UI updates as 
they are coalesced anyway).

—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: observeValueForKeyPath:... called too often in macOS 12

[Jerome Krinock]

> On 2016 Oct 14, at 23:08, Gerriet M. Denkmann  wrote:
> 
> My app (macOS 12) observes a value in NSUserDefaults.  Starting with macOS 12 
> observeValueForKeyPath:… is called at the start of the program, although 
> nothing has changed yet.  When the value actually changes, it is called twice.

I just added some code to one of my apps, to test this.  It confirmed your 
observations, although I only tested in 10.12.

> Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just 
> return NSNull instead of old or new values.

That only happens during that first spurious call, when the observer is added.

> Any workaround for these multiple (and unnecessary) calls?

As always when dealing with undocumented behavior, reverse-engineer :))  
Regarding that initial call, assuming that NSNull is not a legitimate possible 
value, use that NSNull to identify the call as spurious and ignore it.  
Regarding the later duplicate calls, ignore if the new value is the same as the 
current value.  I have seen Cocoa emit such redundant notifications or 
observations in other situations, and have had success filtering them in this 
way.

You can often get clues about such changes in macOS releases by carefully 
searching Apple’s Release Notes for something related, or by filing a 
well-written Bug Report – I’ve received short explanations, anonymous, but 
obviously written by an engineer on the relevant team.  If indeed this behavior 
is new in 10.12, it certainly warrants a Bug Report.


___

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

observeValueForKeyPath:... called too often in macOS 12

[Gerriet M. Denkmann]

My app (macOS 12) observes a value in NSUserDefaults.

Starting with macOS 12 observeValueForKeyPath:… is called at the start of the 
program, although nothing has changed yet.
When the value actually changes, it is called twice.

Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just return 
NSNull instead of old or new values.

Any workaround for these multiple (and unnecessary) calls?

Gerriet.


___

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