Re: controlTextDidChange, backspace possible?
Re: controlTextDidChange, backspace possible?
- Subject: Re: controlTextDidChange, backspace possible?
- From: Harilaos Skiadas <email@hidden>
- Date: Tue, 14 Sep 2004 12:08:20 -0700 (PDT)
--- j o a r <email@hidden> wrote:
>
> When I subclass one of the standard Cocoa classes
> (at least the ones
> not especially designed for subclassing, like
> NSObject,
> NSWindowController, et.c.) I always try to only add
> the absolutely
> minimum of functionality to the subclass, and then
> delegate the rest to
> one of my general controller objects.
Yeah, that is definitely the way I should go. I didn't
lay out my architecture very carefully at that point,
and just dived head in and fixed where I could,
probably bad practice. I'm trying to move focus to the
controller now.
> Why do you need to override the built in drag-n-drop
> functionality?
> Does it not suffice to monitor the
> NSControlTextDidChangeNotifications?
> If you do need to override, have you considered
> creating a custom field
> editor for that purpose?
So, the first key thing is that I don't actually need
to have the drag be dropped in the field. I could just
have the user drop it anywhere in the window. Can I
have my controller handle drops to the window's
content view? If so, what do I need to do? Is that
easier or harder to do?
The point is that the dragged text is a string with
lots of newline characters, and if I just drop it to
the text field, it perceives them as one big thing,
and the way I had set up my program it would add them
to the history list as one command, instead of a list
of commands, one for each line.
I guess the question is, at which point in my code
should I implement the handling of the commands, and
up to now the text field was doing it. Of course, I
want the controller to be doing it. So the main
question remaining is, where should I allow the user
to drop and how to detect that from my controller? Do
I simply set the controller to be the window's
delegate (which it of course is) and then implement
the draggingDestination protocol there?
I guess more generally, can a delegate handle the drag
& drop for a view? If I understand correctly, you are
saying that I could use
NSControlTextDidChangeNotification to do handle the
data dropped my text field after it has been dropped
ther, and no need to mess around with implementing the
dragging protocol to catch while it drops. I am going
to give that a try, but it would be nice if the user
could just drop the thing anywhere in the window.
>
> Note: The text system is probably the most
> complicated piece of Cocoa.
> I would advice against spending too much time on
> bending it to your
> needs, especially as you're new to Cocoa. Get your
Yeah, I definitely don't really want to go there.
> basic functionality
> up and running, and worry about the details later.
>
> > I feel this behavior is a bit buggy. Shouldn't the
> > field editor detach itself from the text field
> when
> > the window loses key status, not only when the
> field
> > loses focus?
>
> Why? The text field is still in "edit mode" even if
> it is not first
> responder.
>
and when I go back to the window it will continue from
where it left off, no reason for it to finish editing
simlply because I decide to move to another window for
a while. I see.
> j o a r
>
>
Thanks for the help,
Haris
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden