Subclassing NSTextView and overriding its designated initializer

Question

Level 1

30 points

Subclassing NSTextView and overriding its designated initializer

Hi

For my app, I'm subclassing NSTextView. I overrode its designated initializer initWithFrame:textContainer: and set the text view's class in IB to my class. However, the initializer is never called. But since it is the designated initializer, it has to be called. Or am I wrong?

Alex

MacBook, Mac OS X (10.4.11)

Posted on Feb 25, 2008 7:24 AM

Reply

Answer 1

PsychoH13

Level 2

445 points

Feb 25, 2008 4:22 PM in response to phunkjoker

Well, first you need to check if the field you put on the window is really an instance of your class.

But the problem might come from somewhere else. Objects in nib files are not code-generated but truly archived using the method -encodeWithCoder: and they are unarchived with the method -initWithCoder:, and even if that method starts with init, that's the only init method that does not call the designated initializer, but only, if any, the -initWithCoder: of the super-class...

That might explain why your designated initializer is never called...

However, what I'd like to know is that if you have good reason to subclass that class...

Okay I just made the test, and it's what I said, the called initializer is not the designated one but the -initWithCoder: hence the designated is never called.

Reply

Answer 2

phunkjoker Author

Level 1

30 points

Feb 26, 2008 2:57 AM in response to PsychoH13

Thank you for your answer, PsychoH13. The only reason I chose subclassing instead of object composition is so that I could easily assign the new class in IB instead of programmatically connecting the text view to a member variable in my class. Also, I had to override a few methods. I assume this is bad practice?

There is something else I was wondering about: Shouldn't the text view and all other controls be deallocated when I close the window? Right now, nothing is deallocated (not even the document instance), and I'm beginning to wonder why I even write dealloc methods...

Thanks,
Alex

Reply

Answer 3

PsychoH13

Level 2

445 points

Feb 26, 2008 3:43 AM in response to phunkjoker

Well, usually, the class defines enough tools for user not having to redefine anything, you need very specific behaviors to have to subclass NS's classes...
So, maybe you didn't search enough and then you didn't find the tool that would be useful for you... What do you want to do exactly ?

For the deallocation, always define a dealloc method even if you think it's never called, it doesn't cost a lot and like that you're sure you're not missing something... However, there's options in the properties of the nib file that can be set for deallocation and memory in general...

Reply

Answer 4

phunkjoker Author

Level 1

30 points

Feb 26, 2008 8:15 AM in response to PsychoH13

You're right - I'm probably better off using object composition instead of subclassing. Right now, the only method I'm overriding is setUsesFontPanel:. But what exactly are the disadvantages of subclassing?

About dealloc: sure, all my classes have a dealloc: method. But it is beyond me why so many objects aren't released (and thus dealloced if the retain count is zero) when they aren't needed anymore. Take my document class, a concrete subclass of NSDocument, for example: when I close a document, I obviously don't need it anymore. However, it is not released, and all the documents that were previously open increase the memory footprint. Or take the terminate: method in NSApplication: obviously, when the application exits, all its memory is freed anyway. But wouldn't it be a lot more elegant if at least the remaining document instances and the application controller instance were released?
I'm probably on the wrong track here as I'm quite new to Cocoa. Are Cocoa programmers expected to write their own close and terminate methods?

Thanks,
Alex

Reply

Answer 5

PsychoH13

Level 2

445 points

Feb 26, 2008 10:20 AM in response to phunkjoker

About subclassing, there's not necessarily a disadvantage, but generally that's useless.
Subclassing is used to add functionalities and behaviors to classes when you really need it.
However, when you can do the things you want with the functionalities that are already available, it's more complicated to subclass than to composite. Especially because it makes your implementation maybe less portable over the time. If there's a radical change you'll have to change the implementation, too...
And also, Apple says multiple times in its documentation that one should avoid bad habits over other programming languages that is for example subclassing a class to add functionalities to it that don't have any link with the first purpose of the class. It gives the example of NSString that should never keep a track of something else than characters, length and eventually encoding. And if you want to add color attributes you can use another kind of class like NSAttributedString.

For the dealloc thing, I know that you can set the behavior of a window in IB for it to be released when it's closed, however, for entire documents I really don't know. Maybe you can look at memory management in NIB files in the Xcode documentation.

Reply