A class can have many initializers. According to the documentation for
NSObject, by convention the initializer that includes a message to
super (usually the one with the most arguments) is the designated
initializer for the class. This initializer should begin by sending a
message to super
All initialized objects have at some point called super; they aren't fully
initialized otherwise. In the implementation, the non-designated initializers
typically chain to the designated initializer, which in turn chains to super's
(usually designated) initializer. So just because a designated i
On Oct 30, 2010, at 12:12, Dave Carrigan wrote:
> All initialized objects have at some point called super; they aren't fully
> initialized otherwise. In the implementation, the non-designated initializers
> typically chain to the designated initializer, which in turn chains to
> super's (usuall
On Oct 30, 2010, at 12:12 pm, Dave Carrigan wrote:
> All initialized objects have at some point called super; they aren't fully
> initialized otherwise. In the implementation, the non-designated initializers
> typically chain to the designated initializer, which in turn chains to
> super's (us
Thanks for the insight.
If calling any of super's initializers will work from the designated
initializer, why then does Apple specifically say the designated
initializer "should begin by sending a message to super to invoke the
designated initializer of its superclass"?
There must be a su
NSWindowController doc states that you should invoke super's initWithWindow:
or initWithWindowNibName:
"In your class’s initialization method, be sure to invoke on super either
one of the initWithWindowNibName:... initializers or the initWithWindow:
initializer"
This breaks the designated initial
On Oct 30, 2010, at 2:17 PM, Quincey Morris wrote:
If you override designated initializer A, then call super's non-
designated initializer B, then B will call A, causing a recursion.
I just tried this exact scenario before I received your email. It
produced an infinite loop just as you predi
Hi everyone,
Given an application path (or NSBundle to an application, etc), is there a way
to easily/efficiently determine what content types that application can open?
My initial attempt was to read the applications Info.plist file and extract the
content types listed under the kUTExportedTyp
I have 2 tableviews (A and B) in a window. Both use Core Data. A 3rd
tableview (in a drawer) has a complete list of items that I can selectively
Drag and Drop to tableview B. I have almost implemented the Drag and Drop,
but one step is missing. Tableview B has a Relationship to an item in
tableview
On 2010 Oct 30, at 16:46, Paul Johnson wrote:
> I have 2 tableviews (A and B) in a window. Both use Core Data. A 3rd
> tableview (in a drawer) has a complete list of items that I can selectively
> Drag and Drop to tableview B. I have almost implemented the Drag and Drop,
> but one step is missing
I have a status item which I'm initialising with a menu like so:
statusItem = [[[NSStatusBar systemStatusBar] statusItemWithLength:
NSSquareStatusItemLength] retain];
NSBundle *bundle = [NSBundle mainBundle];
statusImage = [[NSImage alloc] initWithContentsOfFile:[bundle
pathForResource:@"icon"
On Oct 30, 2010, at 4:46 pm, Paul Johnson wrote:
> I have 2 tableviews (A and B) in a window. Both use Core Data. A 3rd
> tableview (in a drawer) has a complete list of items that I can selectively
> Drag and Drop to tableview B. I have almost implemented the Drag and Drop,
> but one step is miss
12 matches
Mail list logo
