• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: A cursor bug in DragItemAround example
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A cursor bug in DragItemAround example


  • Subject: Re: A cursor bug in DragItemAround example
  • From: an0 <email@hidden>
  • Date: Sun, 27 Apr 2008 14:14:57 +0800

> My guess is that the cursor you set is getting changed back to the
> arrow by the cursorUpdate: method of another view.
>
> IIRC, you have a NSScrollView whose document view (view A) is
> something like a canvas, and has some smaller subviews (each a view B)
> that are like graphic objects on the canvas, which you want to be able
> to drag around.
In fact, I've simplified my program such that it now only has a single
view(i.e., my custom view called DraggableItemView) under the content
view of main window. However, setting initial cursor from
initWithFrame: or awakeFromNib did not work even in such a simple
application, which really disappointed me.
> -- Create a tracking area for view A using options:
> NSTrackingCursorUpdate | NSTrackingActiveInActiveApp |
> NSTrackingInVisibleRect.
Does NSTrackingInVisibleRect option renders the rect specified in
initWithRect:options:owner:userInfo: ignored? Apple's doc reads
unclear to me but my tests turned out that way. If so, that's
absolutely not what I want in this program. As you are to see below, I
need accurate controls of tracking areas in the single view.
> You would do this *only once* for each view. The
> NSTrackingInVisibleRect option takes care of the housekeeping for you
> even if the views change size or position or visibleRect.
>
DraggableItemView spares a rect used as the draggable item, which
appears to be a subview but is actually a region in the view. As a
result, I need update the tracking areas dynamically to reflect the
item's movement; so I need set both the cursor and tracking areas in
mouseUp action, but sadly this way does not work.
> Note also that the cursorUpdate event is a bit strange. When the
> cursor enters a particular tracking area's bounds, the cursorEvent is
> not sent to the tracking area's owner (like mouseEntered/mouseExited
> are), and it's not sent to the view that the tracking area was
> installed into. It's sent to the topmost view under the mouse pointer,
> whatever that may happen to be.
Thanks for your notice. I believe I will meet such situations when I
build more complex applications.
_______________________________________________

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

References: 
 >A cursor bug in DragItemAround example (From: Ling Wang <email@hidden>)
 >Re: A cursor bug in DragItemAround example (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: Debugger at odds with reality?
  • Next by Date: Re: Core Animation Flickering
  • Previous by thread: Re: A cursor bug in DragItemAround example
  • Next by thread: Re: A cursor bug in DragItemAround example
  • Index(es):
    • Date
    • Thread