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: Daryn <email@hidden>
- Date: Fri, 11 Jul 2003 16:28:25 -0500
If I'm leading you astray, perhaps Douglas can send you his standard
spiel on the topic (which I received when doing the exact same thing
you are doing). Or search mamasam, he's sent it to a number people.
Fighting the AppKit leads to nothing but frustration. If you do it the
AppKit way, it becomes amazing simple and elegant.
On Friday, July 11, 2003, at 02:07 AM, Sailor Quasar wrote:
On Friday, July 11, 2003, at 12:06 AM, Daryn wrote:
For simple bindings, implement the NSTextField's delegate
control:textView:doCommandBySelector:. If I recall correctly, opt-up
& opt-down are translated into the responder selectors
moveToBeginningOfLine: and moveToEndOfLine:.
This might work, but it neither addresses the control's action (which
I do with the subclass of NSTextField anyway), nor the fact that those
selectors are in no way guarnateed to be bound to those keys in the
current or any future version of the OS; my understanding is that the
key bindings are read from a dictionary file of such on disk that the
user can modify at will and that the programmer has no control over.
For the key bindings, that's definately true. If you are concerned,
then use one of the methods below instead.
For more complicated keystrokes, use NSWindow's delegate
windowWillReturnFieldEditor:toObject: to replace the field editor for
your cell with a subclass of NSText or NSTextView. In your custom
field editor, override keyDown: to catch and process your special
keystrokes. The delegate of your custom field editor will be set to
the control, so you can then use the control's delegate to get to
your external controller object.
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;
}
If you can directly use a NSTextView, then try the delegate's
textView:doCommandBySelector: to trap the responder selectors, or
implement implement keyDown: in a subclass.
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:.
Daryn
_______________________________________________
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.