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

inconsistencies in view renderings

[Alan Snyder]

I am not an expert on Interface Builder, so I hope to learn something about how 
IB simulates the display of views or how IB defined views are constructed at 
run time.

I have a UI that includes textured rounded buttons with text labels. In IB, 
when the IB window is inactive, the buttons display in a grayed out fashion. In 
the actual application, when the application window is inactive, the button 
displays do not change.

What might be causing this difference in rendering?

  Alan


___

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: Optimization Level

[Jens Alfke]

> On Oct 17, 2016, at 11:35 AM, Raglan T. Tiger  wrote:
> 
> void x::Clear(apointList )
> {
>if ( !  )
>return;
> }

It’s not valid for a C++ reference value to refer to null. So the optimizer is 
allowed to assume that `` is a non-null pointer, and the test in the `if` 
can never be true, and optimize out the whole `if` statement. You’ll need to 
restructure your code so that you never pass null values as references.

I ran into a similar situation a while ago, where I had a (nonvirtual) method 
that accepted a null receiver, i.e. it was safe to call `foo->bar()` even if 
`foo` was null because the method had a test `if(!this) return;`. But the C++ 
standard says that it’s illegal to call a method with a null receiver, so the 
optimizer removed the test.

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

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

Optimization Level

[Raglan T. Tiger]

Moving , finally, to Xcode 7.3.1, I get a weird bug.

If I build a release configuration with the recommended optimization level 
(fastest, smallest) then this code

void x::Clear(apointList )

{

if ( !  )

return;

}

never returns when apointlis  = 0x as shown in the debugger.

But if I set the optimization level (none) then the code works properly.  

Of course Apple says never ship release code with optimization level none, 
always use faster,smallest

What am I missing ?

-rags
___

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