> On 19 Oct 2016, at 11:43,Jerome Krinock <je...@ieee.org> wrote:
>> On 2016 Oct 18, at 19:32, Gerriet M. Denkmann <g...@mdenkmann.de> wrote:
>>> On 19 Oct 2016, at 02:00,Jerome Krinock <je...@ieee.org>:
>>>> On 2016 Oct 14, at 23:08, Gerriet M. Denkmann <g...@mdenkmann.de> 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 

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,



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:

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

Reply via email to