• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: initWithFrame fails
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: initWithFrame fails


  • Subject: Re: initWithFrame fails
  • From: N!K <email@hidden>
  • Date: Tue, 30 Dec 2014 11:33:08 -0800

>
> So, ‘init’ is the designated initializer of NSObject, but not of NSView. NSView’s designated initializer is ‘initWithFrame:’. If you wrote code to send ‘init’ to a NSView object, I’d expect you’d end up at ‘initWithFrame:’ — in class NSView, ‘init’ is a convenience initializer.

This answers me very well. I have used multiple inits under NSObject, but I completely forgot that’s not so in NSView.

>
> ‘initWithCoder:’ is implemented in many classes, but you don’t know in general whether it’s a[nother] designated initializer or a convenience initializer. IOW, you don’t know, in terms of class machinery, whether -[NSView initWithCoder:] is supposed to invoke -[NSView initWithFrame:] or not. However, in this case, the resource loading guide suggests that one or other is invoked, but not both, so I guess they’re both designated initializers.
>
>> I need to know why initWithFrame stopped working, how to use initWithCoder:  correctly, and what potential pitfalls are out there. There may be more than this one:
>> WANNABEGEEK:“ Identity Inspector - User Defined Runtime Attributes
>> In your implementation class you cannot use initWithCoder: otherwise your key-value path setting will not be picked up. You will have to do all your implementation within awakeFromNib.”
>> Clearly I have some studying to pursue, after this fine start you have given me.
>
> Be careful before putting your faith in information that comes from the Internet.

True. I test them carefully. The few faults have been obsolete info.

> It may have been true once but false now. It may be somewhat useful and technically inaccurate at the same time. This particular gem seems like an example of the latter.
>
. . .


> If you think about it, this makes sense in terms of initializers. The NSCustomView placeholder object is in fact unarchived from the NIB file, so it gets initWithCoder:. The replacement object of your class is created directly, so it gets initWithFrame:.
>

This sets me straight. I appreciate all the effort that has gone into getting me going again on the right track, with education as well as instruction.

Nick
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


References: 
 >initWithFrame fails (From: N!K <email@hidden>)
 >Re: initWithFrame fails (From: Kyle Sluder <email@hidden>)
 >Re: initWithFrame fails (From: Roland King <email@hidden>)
 >Re: initWithFrame fails (From: N!K <email@hidden>)
 >Re: initWithFrame fails (From: Quincey Morris <email@hidden>)

  • Prev by Date: Switching branches ignores Deployment Target immediately
  • Next by Date: Re: Switching branches ignores Deployment Target immediately
  • Previous by thread: Re: initWithFrame fails
  • Next by thread: Re: initWithFrame fails
  • Index(es):
    • Date
    • Thread