Re: Dragging to text fields
Re: Dragging to text fields
- Subject: Re: Dragging to text fields
- From: Bill Cheeseman <email@hidden>
- Date: Fri, 15 Mar 2002 17:58:42 -0500
on 02-03-15 5:02 PM, Douglas Davidson at email@hidden wrote:
>
This shouldn't be terribly surprising; after all, everything works
>
correctly if the target field is already editing, right? We might even
>
have done this by default before now, except for concerns about such
>
things as the effects of suddenly ending editing on the source. It's
>
something that probably deserves further consideration.
I've been playing around with it all afternoon, and I've encountered only a
couple of downsides (both associated with formatters connected to the
destination text field):
1. If an on-the-fly formatter connected to the destination text field
rejects the drop, I don't get the slideback behavior that is supposed to
give visual feedback that the drop was rejected. (I believe this is a side
effect of the fact that I lose control of the dragging session as soon as
the draggingEntered: method hands over control to the field editor. My
draggingUpdated:, draggingExited:, etc., methods are not called. I suspect
the field editor's dragging mechanism thinks the source of the drag is the
point where it took over, namely, at the boundary of the destination.)
2. If the drop violates a non-on-the-fly formatter, I don't learn about it
until later, when the the illegal entry is committed by pressing Enter, etc.
Unfortunately, this includes dropping something on another text field. So
the moment I try to drop something on the second text field, the first text
field is committed and triggers the formatter's error (a beep, a sheet, or
whatever). This is awkward and confusing when I am dragging from another
application into a destination text field in a background window, because
its icon in the dock starts bouncing, and I have to activate the destination
window to deal with it, and by now my attention has moved on to the second
text field.
To cure #2, I need to commit the data at the time of the drop to trigger any
illegality warning immediately. Unfortunately, since I've lost control of
the dragging operation, I can't do this in a performDragOperation: or
concludedDragOperation: method. I can't find a way to force the drop to
commit the data, although this seems like it should be default behavior in
the case of a drag to a background window. Is some notification posted at
the time of the drop? -- I thought I saw one earlier today, but now I can't
find it.
(I'm doing all this from a category on NSTextField, by the way, so as to
avoid subclassing NSTextField. This lets me apply dragging to any text field
of whatever subclass, just by registering it. A nice substitute for multiple
inheritance. But it means I can't use instance variables, or override text
field methods, which restricts what I can do.)
--
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.