Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
- Subject: Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
- From: Mike Abdullah <email@hidden>
- Date: Fri, 22 May 2015 14:18:54 +0200
> On 22 May 2015, at 13:51, Jonathan Taylor <email@hidden> wrote:
>
> I’m trying to think if there is an elegant way of handling the situation I find in some of my display code. I have a class which inherits from NSView and which overrides drawRect. The class has a number of properties, and if they change then the view needs redrawing. At present I have custom setters that call through to setNeedsDisplay:YES. This results in quite a lot of code bloat (since I would otherwise just @synthesize the properties and be done with it).
>
> I could set an observer on each property, but that would be a bit tedious (especially since, as I understand it, I have to remove EACH of the observers individually as well on dealloc).
>
> I am trying to think if there is a way I can leverage keyPathsForValuesAffectingValueForKey to make things a bit simpler. I’m quite a fan of using that where I can. It would be great if I could say that all my properties affect some particular property of NSView that would trigger a redraw. I can’t think of one that would do the trick, though. [If you think about it, the property needsDisplay is NOT the one I want to say is affected by my keys…]
>
> I could create a single “dummy” property of my own, say that changes to all these other properties affect that key, and then monitor that single key using KVO (and call setNeedsDisplay whenever it gets “tickled” by some other property change). That would do what I want, but feels a little bit hacky.
>
> Does anybody have any thoughts about what I might do? I feel this is probably a relatively common problem that people must have a way of dealing with…
Well you could have a single key which you observe internally, and which all the other keys feed into. Whenever it “changes”, treat that as time to mark as needing display. That way you’re asking AppKit to do the work of creating all the other observations for you.
It all seems rather wasteful though. You’ve added a couple of layers of indirection into the system to save a handful of lines of code. Is it really that big a deal to write some custom setters? They’re only four lines long each.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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 email@hidden