Re: inconsistencies in view renderings

On Oct 17, 2016, at 21:16 , Alan Snyder wrote: > > 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 renderi

Re: inconsistencies in view renderings

Is the choice to gray or not to gray when inactive under programmer control? > On Oct 18, 2016, at 12:08 AM, Quincey Morris > wrote: > > Keep in mind that buttons have *two* kinds of graying these days. One > indicates that the button is disabled. The other indicates that the button is > in

Re: inconsistencies in view renderings

On Oct 18, 2016, at 08:00 , Alan Snyder wrote: > > Is the choice to gray or not to gray when inactive under programmer control? IIRC you can control this by the the value of “acceptsFirstMouse”. The NSView default is NO, but NSButton overrides it to return YES. To change it back again, you nee

Re: inconsistencies in view renderings

I was afraid you would say that… The implication is that AppKit is probing the application at unspecified times with a fake event? Nothing in the documentation of acceptsFirstMouse suggests such a thing. I have not found any other API so far. Alan > On Oct 18, 2016, at 9:51 AM, Quincey Mo

Re: inconsistencies in view renderings

On Oct 18, 2016, at 12:17 , Alan Snyder wrote: > > The implication is that AppKit is probing the application at unspecified > times with a fake event? Well, I had to try it in a test project. I don’t see *any* difference in appearance in the buttons, with acceptsFirstResponder YES or NO, regar

Re: inconsistencies in view renderings

Sounds like you were not using textured rounded buttons, which are the ones that I wrote about. > On Oct 18, 2016, at 1:00 PM, Quincey Morris > wrote: > > On Oct 18, 2016, at 12:17 , Alan Snyder > wrote: >> >> The implication is that AppKit is probing t

Re: inconsistencies in view renderings

On Oct 18, 2016, at 17:58 , Alan Snyder wrote: > > Sounds like you were not using textured rounded buttons, which are the ones > that I wrote about. I tried one of those and one regular button, and the textured rounded didn’t seem to change at all. Note that IIRC you’d normally use textured ro

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

> 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. Wh

Re: inconsistencies in view renderings

That sounds rather mysterious. What kind of project configuration would affect the display of buttons? Well, try this on Sierra: Use the Open File… menu item of Safari to open a dialog. Then activate a different application. On my system, the Cancel button in the dialog grays out (although it

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

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/

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

> 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.

Re: inconsistencies in view renderings

On Oct 18, 2016, at 19:43 , Alan Snyder wrote: > > Well, try this on Sierra: > > Use the Open File… menu item of Safari to open a dialog. Then activate a > different application. On my system, the Cancel button in the dialog grays > out (although it still looks different than the disabled Open

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

> 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 addO

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

> 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 NSKeyValueObserving

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

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 Tex

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

> 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

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

> 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 qui