Re: Making Tiger Look Pretty in Drag
Re: Making Tiger Look Pretty in Drag
- Subject: Re: Making Tiger Look Pretty in Drag
- From: Martin Redington <email@hidden>
- Date: Sat, 17 Nov 2007 15:10:20 +0000
I'm using a method similar to the one described below, to support
changing images mid-drag (although on Leopard rather than Tiger).
I have a transparent window, with a smaller view (I haven't
implemented the swapping yet) that is the same size and shape as the
original dragging source.
As the source receives draggedImage:movedTo: messages, I move the
transparent window, with the custom view that draws the pseudo
dragged image.
The problem I'm having is as follows:
When I move (programmatically) the transparent window so that the
cursor is over the window (rather than the view), the dragging
destination receives draggingEntered:, draggingUpdated: and
draggingExited: messages as expected.
When I move the transparent window so that the cursor is over the
view, the dragging destination never receives the dragging
destination messages, as though the view was somehow swallowing them up.
I tried fiddling with the transparent window level, as mentioned in
the thread below, but it seemed to make no difference. I really do
want to keep the cursor over the view (in the same relative location
as it was when the user initiated the drag) for aesthetic/useability
reasons.
Is there any easy way to stop the view interfering with the dragging
destination calls?
FROM : David Masters
DATE : Mon Oct 15 23:13:14 2007
Hi,
On 15 Oct 2007, at 20:56, I. Savant wrote:
> 1 - How can you change a drag image, mid-drag, in response to
> arbitrary modifier flag changes and possibly other events?
> 2 - Is it possible to animate the drag image as in Dashboard's
> drag-from-dock action?
> Searching the archives and the web at large gives me very little
> hope of any supported way to achieve this without some nasty code.
I wanted to do this second option - animating the drag-from-dock
action - and arrived at the same conclusion after searching the
archives and web.
> I'm thinking of the following:
>
> 1 - Returning an empty image (returning nil upsets Cocoa).
> 2 - Implementing -draggedImage:began/movedTo/ended... to message my
> Pretty Drag mechanism and update it.
> 3 - Respond (via my Pretty Drag mechanism) to these update
messages by
> positioning a transparent window with a view that renders my
animation
> any damned way I please.
>
> Anyone got a problem with that? ;-)
No problem at all - that's pretty much the approach I took. :-)
1. Created a window controller to manage the overlay window, and
passed in two images: one for the small icon representation, the
second for the larger representation. Initiate the drag as normal with
-dragImage:at:offset:event:pasteboard:source:slideBack with an empty
image to keep things happy.
2. In -draggedImage:movedTo: reposition the overlay window to the new
position; if the position was outside the dock region get the window
controller to swap representations.
3. In response to a request to swap representations, I used
NSViewAnimation to cross fade between two views containing the
required images.
The tricky parts that seemed to cause problems (for me at least!) were
the level of the overlay window - NSFloatingWindowLevel caused me to
have problems with the drag not being registered in destination views,
but higher levels worked. Also the slideback action doesn't work if
you're just moving the overlay window in response to -
draggedImage:movedTo:.
I also found it easier to keep the overlay window at the maximum size
necessary for both images rather than attempting to scale it during
the cross-fade - it seemed to judder more than I would have liked.
I'd be happy to share the code but not just yet - it contains some
Leopard-specific code (though it should be easy to convert for use on
Tiger), and it needs a bit of cleaning up.
David
David Masters, Captain of the CocoaCheerleaders :-)
<email_removed>
Web: Blog: <A href="http://blog.cocoacheerleaders.com";>http://
blog.cocoacheerleaders.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden