Re: cocoa-dev digest, Vol 2 #933 - 14 msgs
Re: cocoa-dev digest, Vol 2 #933 - 14 msgs
- Subject: Re: cocoa-dev digest, Vol 2 #933 - 14 msgs
- From: Bill Cheeseman <email@hidden>
- Date: Fri, 12 Jul 2002 19:05:14 -0400
on 02-07-12 4:16 PM, Paul Fox at email@hidden wrote:
>
> The method you're looking for is -[NSCell setScrollable:]. Just
>
> call it on the NSTextField's cell and you should be set.
>
>
>
> --
>
> Brian Webster
>
> email@hidden
>
> http://homepage.mac.com/bwebster
>
>
I'm a little confused...maybe someone can help.
The essential nature of Objective-C and the Cocoa frameworks -- the soul of
this thing we all love so much -- is attempting to seduce you, but you are
foolishly resisting. You're struggling hard to impose procedural language
concepts on your task, when Objective-C and Cocoa are designed to just let
it happen for you. There is truth to the old Cocoa saw that, if you're
finding it very hard to do what you want to do, you aren't approaching the
task correctly.
An NSTextField object has an NSTextFieldCell embedded in it, so to speak.
This is not an inheritance relationship, but a containment relationship. It
is very common in Cocoa user control classes, especially those that display
text. You will find NSTextFieldCells embedded in table views, forms, combo
boxes, and, of course, text fields, as well as other text-based controls.
You noticed that NSTextField inherits from NSControl. As you discovered, it
is always important to look at the superclasses. For example, you looked at
the NSControl header file or class reference document, and you found a
method named "cell." This method returns a reference to the cell embedded in
the text field, should you care to do anything with it. So, your NSTextField
object can obtain a reference to its embedded NSTextFieldCell, via its
parent NSControl class, by sending this message: [self cell].
NSTextFieldCell inherits from NSCell (with an NSActionCell sandwiched in
between). So, your NSTextField object can obtain a reference to its cell's
scrollable property by sending this message: [[self cell] scrollable]. Or it
can set its cell's scrollable property by sending this message: [[self cell]
setScrollable:YES]. In the case of some more complex user controls, such as
an NSForm object, you might send this message, instead: [[self selectedCell]
setScrollable:YES], or one of its similar methods using the cell's index or
tag.
>
I am creating an NSTextField in order to create a normal
>
editable field. Is this correct?
>
>
The method stated is for NSCell and NSTextField is not derived
>
from NSCell - although NSTextFieldCell does obviously derive from this.
>
>
I'm not sure what I am doing wrong -- using NSTextField in the first place?
>
But if I try to use NSTextFieldCell then it has the 'wrong' methods
>
I need. (If I should be using NSTextFieldCell then hopefully
>
I can map my method calls).
>
So, yes, you are correct to use NSTextField as the base class for a text
field in your window. And you can easily set and reset its scrollable
property at will by working with its embedded cell as described above.
I'm not sure what you mean by NSTextFieldCell having the "wrong" methods. I
think you probably believe you have to treat the text field either as a text
field or as a cell. But in Cocoa, it isn't exclusive; you use whatever
facilities the text field offers. The embedded cell has the right methods
for the tasks it knows how to perform, such as setting its scrollable
property. At the same time, you would use the text field itself, or its
superclass, for other purposes. It just depends on which class has the
methods you need. Everything is compartmentalized in Cocoa, usually in very
sensible and obvious ways, once you get the gist of it.
In this case, using the embedded text field cell is enough. But in many
other cases, you will encounter an even more interesting Cocoa and
Objective-C phenomenon. Cocoa is full of classes declaring methods having
identical names, even though they aren't in the same inheritance tree. These
methods are in fact independent and different, although they bear the same
name. Despite the fact that they are separate methods, which happen (by
foresight) to have the same name, you can write your messages using the
name, and the Objective-C runtime engine will figure out at run time which
class's method having that name it wants to call. This is a result of what
is called runtime binding, which is what makes Objective-C a "dynamic"
language. But that isn't relevant to your questions.
>
I've read about NSWindow having a single editing window which is remapped
>
as needed to the appropriate responder cell. Is this implying I
>
should be capturing this remap and doing setScrollable: on that thing
>
as it bumps around?
Yes, there is a "field editor" which does the actual work of handling your
typing in any NSTextFieldCell object, no matter what user control object it
happens to be embedded in. But no, the field editor has nothing to do with
setting the scrollable property of the cell. You handle the scrollable
property as described above, without paying any attention to the field
editor. The field editor is instantiated from yet another class, NSTextView
(or its parent, NSText; it's kind of hard to tell which), which is a very
complex Cocoa topic. Basically, the text view that is the field editor knows
how to deal with all the keystrokes you might type while editing any text
control. You'll have plenty of reasons to play with it, but controlling the
scrollable property of a text cell is not one of them.
>
Just browsing NSControl - which has a cell: method. Is this the baby
>
I need -- grab the cell: from the superclass, then set the attribute
>
there?
Yep. As described above.
>
If so, can anyone explain this object hierarchy to me? Why have
>
a 'shadow' object in the superclass? Seems a little bit bizarre to me,
>
but maybe its for some form of efficiency (multiple inheritance - kinda)?
It isn't really an "object hierarchy" you're trying to understand, but more
of an object "network" with some hierarchies included. Referring to the cell
as a "'shadow' object" or "multiple inheritance - kinda" is very
perspicacious. You're on the right track.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.