Re: Deleting contents of NSTextView...
Re: Deleting contents of NSTextView...
- Subject: Re: Deleting contents of NSTextView...
- From: Bill Cheeseman <email@hidden>
- Date: Mon, 01 Jul 2002 10:59:36 -0400
on 02-06-30 10:10 PM, Sherm Pendley at email@hidden wrote:
>
Still, it seems odd; one of the things that I find appealing about
>
Cocoa, compared to Swing, MFC, GTK, etc., is its self-consistency.
>
That's why it strikes me as odd that, while NSControl and NSCell (which
>
doesn't inherit from NSControl) have setStringValue: methods, the NSText
>
and NSString methods that serve the same purpose are called setString:
>
instead.
Here's my (very tentative) take on this. I would welcome feedback because
I'm not really sure.
NSTextView isn't a control -- neither by inheritance nor in concept. For
example, it doesn't want to send an action method on end editing, according
to its Interface Builder Info Panel's Attributes pane, as controls do. Its
data should be updated on the fly as the user types, cuts, pastes, etc.,
using the textDidChange: delegate method as needed to keep the text view and
its data store synchronized. Not needing an action method or some other
explicit end-editing signal makes it possible to save the current contents
of the text view without requiring the user to give some signal that editing
is done. As I program an NSTextView in a window, I find myself taking a
completely different approach than I do with user controls.
You can find lots of examples where people try to force a text view into the
mold of a control, but they all seem very awkward to me. For example, by
intercepting the Enter key and treating it as a signal to end editing, or
even by putting a Done button near the text view, all to force the text view
to resign first responder status just to send its textDidEndEditing
notification so they can emulate a control's action message. But none of
this is necessary, because the textDidChange delegate/notification allows
you to do whatever you need to do without requiring the user to "commit" the
data. You just type in it when you want to, and save the document when you
want to -- nothing else is required.
From this point of view, having a setString: instead of a setStringValue:
method seems reasonable. In a control, you are setting its value, as
opposed, say, to its state (NSOnState, NSOffState, etc.). In a text view,
it's more natural to think of it as *being* a string (or an rtf or rtfd
NSData object). A text view doesn't have a state in the same way a control
does (or some of them do). A text view isn't used to *control* anything, but
controls (usually? often?) are, or at least can be.
Comments? Am I barking up the wrong tree?
--
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.