On Dec 26, 2014, at 11:53 AM, N!K <[email protected]> wrote:
> > On Dec 24, 2014, at 9:16 PM, Lee Ann Rucker <[email protected]> wrote: > >> In addition, does your code have to be in initWithFrame:? > > No, as it turns out, although I don’t yet understand why. Please see my reply > to Roland’s email. Well, I meant "has to be there" as in "needs to to be set at init time *and* needs to use the frame". There are many other places to set values - awakeFromNib, KVO observers, in a custom setter, in a local variable as part of your drawing, etc. init isn't very flexible when it comes to setting values; you only get one shot at it and your object may not be fully configured - there's no reason the frame you get actually has to be valid, for instance; making views with NSZeroRect and then setting them once you know more about where they are is a common pattern. > >> There's also awakeFromNib, at which point your view will have its frame set, >> if that's what you're depending on. And if it is frame dependent, what >> happens when the frame changes? >> ________________________________________ > >> > > > Sorry, I don’t know what you mean by “frame dependent.” If your init code were doing something like self.path = [NSBezierPath bezierPathWithRect:frame]; then as soon as the view's frame changes, your path will be out of date. (It would also be relative to the wrong coordinate space, but I'm just doing it for example's sake) That's a dependency, and the solution to that is Key-Value Observing (KVO), which is well worth studying in detail - the learning curve is a bit steep but for complicated interdependent values it's invaluable. _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
