Re: Easier way to make NSView subclasses refresh on a property change?

> On Feb 2, 2016, at 11:05 PM, Graham Cox wrote: > > Hi all, > > Whenever I make a custom view class, it often has a bunch of properties that > affect the content it renders. So, for each setter that does this, I have to > override the setter, do whatever it normally

Re: Easier way to make NSView subclasses refresh on a property change?

[self addObserver:self forKeyPaths:[Foo keyPathsThatAffectDisplay] ...context:SomeUniquePtrValue]; (We have a class addition to NSObject to take an array of keyPaths and lopp through addObserver:forKeyPath: etc, because we use multiple key paths *everywhere*) - (void)observeValueForKeyPath:

Re: creating draggable NSView

OK, cancel that. As so often happens when I finally give up and ask a question, the answer hit me the face a few minutes later. Still hurts, too: trouble was that in an earlier experiment I had overridden setFrame: in this derived class and had neglected to remove that - it was not configured

Re: [swift-evolution] #available has a huge anti-pattern.

On Feb 3, 2016, at 3:29 PM, James Campbell wrote: > > We could only allow objective c methods to be queried by responds to But then the check is faulty, because it can find private methods. > But how do we handle Linux or any of the other platforms are you saying we >

creating draggable NSView

Colleagues, I have been trying to create a draggable NSView for OSX and am stumped by the stubborn refusal of the view frame to change. Here's the essence: in responding to a mouse drag there is a place where I do this; NSPoint newLocation = event.locationInWindow; NSRect frame = self.frame;

[NSThread callStackSymbols] weirdness

I am trying to track down a difficult bug on a customer's machine. I have inserted [NSThread callStackSymbols] at a critical place in the app where I want to see how it got there. When running a debug version, either in the debugger or not, I see: 2/3/16 10:53:51.070 PM MyApp Core[22398]: (

Re: creating draggable NSView

> On Feb 3, 2016, at 4:28 PM, Jeff Evans wrote: > > Does anyone have a clue as to why that frame would not alter after setFrame: > with a new value? Constraints, probably. —Jens ___ Cocoa-dev mailing list

Re: UIViews in SpriteKit Apps

The difference in visual style is something I’m considering. I’m hoping to use the standard system pickers, but adjust the colors to fit my game’s aesthetic. I’m still a real iOS noob, so even though I think it can be done, maybe I’m wrong. Thanks for the modal view controller idea: I’ll start

Re: View-based NSTableView and ending editing with "return"

> Le 24 janv. 2016 à 09:51, Arved von Brasch a écrit : > > Hello list, > > After putting it off for too long, I’m migrating to view-based NSTableViews. > I’ve worked through most of the conversion problems I’ve had, and am > generally pretty happy. There is, however, one

Re: Easier way to make NSView subclasses refresh on a property change?

Set a key value observer for each that would call the refresh method. If there's a way to cluster them all into a collective set of things that would change (I think there may) I'm interested in hearing about it too. Would it be possible (or wise) to add them to an array or set and put the