Subclass

No. This has absolutely 100% nothing to do with subclassing. All you are doing is creating an instance of NSButton.

I suggest you need to learn the basics of Object Oriented Programming.

 

Robbie's right, the term subclass in that context doesn't make sense. Can you quote an example? Please quote exactly and don't paraphrase, otherwise we can't correctly explain it to you.

 

The way I was originally taught about subclasses was the animal example.

All animals in the real world have characteristics and actions, which lends itself to an object. But there are different kinds of animals, so you can subclass Animal.

For instance, you have a class Animal, with properties such as legs, communication method, size, etc. Now, suppose you want to create a Cat. This cat is an animal (and importantly, a Cat is an Animal!), but posses a unique characteristic: the boolean canAlwaysLandOnFeet. Instead of making a Cat that duplicates the characteristics of an Animal and adding that boolean, you can simply subclass Animal into a Cat. (A Cat inherits all of the methods/properties from Animal.) You would then only have to add the canLandOnFeetAlways property to Cat, saving yourself a lot of work. This would be especially true if you wanted to add a property such as hair color, which all animals have. Just add it to Animal, and it automagically becomes part of Cat.

If you had a class Animal, creating a class Cat based off of Animal would be subclassing Animal, resulting in a distinct class that happens to be a subclass.

I hope this answers your question well. I might have gone off what a subclass is more than how to properly use the word, but maybe this example will help with that, too.

 

@Thom_Edwards's analogy is great. To put it into context for Cocoa apps, take a look at Figure 1-8 from this documentation. It shows the App Kit class hierarchy. So you can see for example that NSPanel inherits from NSWindow which inherits from NSResponder which inherits from NSObject. This means that an instance of NSPanel object can use the methods of NSResponder for example.

In the case of the button, you're likely not subclassing NSButton (unless you're trying to make some crazy new type of button like a triangle button or something like that) but you're instantiating 1 unique instance of the NSButton class and giving that instance a name. To refer back to the animal analogy, you're not subclassing cat (and breeding some new species of glow-in-the-dark cat), but you're instantiating (giving birth to) and giving the name to one individual cat: mrWhiskers.

In the other thread I was suggesting you subclass NSWindowController. In this case, you want to create a unique "species" of NSWindowController one that handles the preferences of your app, it's buttons and does the things that a LARSPreferencesWindowController would want to do. You accomplish this by subclassing NSWindowController. This new "species" can do all of the things it's parent class NSWindowController can do, and it's parents etc, but you can add the additional specific variables and methods that will be unique to making a LARSPreferencesWindowController do what it does (displaying crit boxes etc.).

You will still need to create an instance of this class or potentially several instances if you had a need for multiple preference windows open simultaneously (not likely but possible in theory); in this case, each LARSPreferencesWindowController instance would manage it's own unique set of buttons, textfields etc.

I hope this helps clarify things a bit.