Re: Making Tiger Look Pretty in Drag

  • 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: ">http://
    > blog.cocoacheerleaders.com
  • -[NSWindow setIgnoresMouseEvents] solved this for me ...

    On 17 Nov 2007, at 15:10, Martin Redington wrote:

    >
    > 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: ">http://
    >> blog.cocoacheerleaders.com

    >
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today