Re: NSTextField, NSTextFieldCell, NSTextView... this is a mess, I need help
Re: NSTextField, NSTextFieldCell, NSTextView... this is a mess, I need help
- Subject: Re: NSTextField, NSTextFieldCell, NSTextView... this is a mess, I need help
- From: Sailor Quasar <email@hidden>
- Date: Fri, 11 Jul 2003 18:20:18 -0400
On Friday, July 11, 2003, at 05:28 PM, Daryn wrote:
That requires that I know how to create an NSTextView subclass
correctly. I already tried this approach, only to have the field
never appear in the running program at all. I'm also not satisfied
with it since it requires working with the window, even though it's
the window's delegate. The ideal here is to have the text field be a
self-contained subclass that only reacts when it gets events relevant
to itself.
You only need to override keyDown: in the subclass. It's that easy.
Put some NSLog's into the source to debug why you are having
difficulty replacing the field editor in
windowWillReturnFieldEditor:toObject:. You requested a solution that
involved using delegates rather than subclasses, and that's what I've
suggested.
To make the object more "self-contained", do what I did:
- (id)windowWillReturnFieldEditor:(NSWindow *)sender
toObject:(id)anObject {
id editor = nil;
if ([anObject respondsToSelector:@selector(preferredFieldEditor)])
{
editor = [anObject
performSelector:@selector(preferredFieldEditor)];
}
return editor;
}
Ideally, I wouldn't have to do anything in the window at all, delegate
or subclass, but nothing's perfect.
Again, I've tried overriding keyDown in subclasses, see my last
response. I can only guess that I must be missing something. There's
no way to substitute a field editor without an NSWindow delegate,
since a subclass of NSTextFieldCell yields the same nothing-appears
results.
If you directly use a text view (ie. forget about a text field,
configure the view to look and act like a field), then there is no
need to worry about swapping in a custom field editor -- the text view
IS the field editor. Simply implement keyDown:.
Sounds an easy, elegant, perfect solution... until you look at the two
problems:
1) I can't define a custom NSTextView subclass in IB, nor can I size it
to the required height. Easy enough to get around, just use the
window's -awakeFromNib to create the view (I don't consider that the
same as implementing the field's code in the window). Why IB insists on
displaying only the enclosing NSScrollView in the Custom Class panel is
beyond me, but with that enclosing view, I can't resize the thing to be
only a single line tall either. I've 9/10 of a mind to file a bug
against that.
2) NSTextView is not a subclass of NSControl or NSActionCell, and
therefore does not have a -sendAction, which is what I currently use to
tell the application controller that I have input to process. I could
intercept \r and \n in keyDown and route them into the controller's
IBAction (or even add a target and action sequence to the subclass if I
didn't want to keep specific references around), but while intercepting
\r and \n would be more ideal for me than the NSTextField's way of
sending actions whenever you click/tab out of the field, something in
me gets the feeling that they're not a good thing to rely on...
Maybe I'm just crazy. The compiler warnings for multicharacter
constants when I do comparisons like [string characterAtIndex:0] ==
'\0#' are driving me slowly insane. I know that's really not a good
tactic to use, but I can guarantee that the input to my NSStrings is
pure 7-bit ASCII so I can afford to assume that the UniChar output
always has a 0x00 high byte.
-- Sailor Quasar, High Codemaster of the Web, scourge of systems
cvs server: Updating Quasar/brain/caffiene
A pepsi
R coke
Email: email@hidden
_______________________________________________
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.