• 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
Odd interaction of NSTrackingArea behaviour with drag and drop
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Odd interaction of NSTrackingArea behaviour with drag and drop


  • Subject: Odd interaction of NSTrackingArea behaviour with drag and drop
  • From: Luke Evans <email@hidden>
  • Date: Tue, 10 Mar 2009 19:41:25 -0700

I have tracking areas set up in an NSTableView,similar to the Cocoa PhotoSearch sample app, and these have the NSTrackingEnabledDuringMouseDrag option set. There may be various definitions of what "mouse drag" actually means, but the docs just indicate that this option should produce tracking events when the mouse is moved through a tracking area with buttons pressed (q.v. NSTrackingArea Class Reference, Constants).

By and large tracking areas are working well, though I've had one true work-around for some odd behaviour during autoscroll (per an earlier thread here).

Now though, I've come to implement drag and drop onto my table cells and have noticed immediately that things go pear-shaped with (seemingly) externally initiated drag and drop.
As an item (e.g. from the finder) is dragged across the tracking areas I get frequent but intermittently timed mouseEntered - mouseExited event pairs. These are sent to the control even when no tracking area boundary is being crossed, for instance when the mouse is just dragged up and down a cell/single tracking area.


I have a test app that recreates the problem in what I consider a reasonably sterile environment.. This consists of an NSTableView that defines a single tracking area that covers the area of a single cell in the table. Dragging an item over this cell, produces the same stuttering event-pair messages that I'm seeing in my main app - again with no tracking area boundary being crossed.

Are these conditions familiar to anyone? Should I expect tracking areas to work for drags started in other apps?

Obviously, I'd be keen to learn if tracking areas aren't supposed to work in 'normally' in during drag/drop, or if there are considerations I may have overlooked regarding how to set them up or how to keep them happy alongside other messaging that is invariably happening (table datasource drag/drop messages etc.). However, to the last point, my test app elides all extra flora and fauna besides setting up the tracking areas and writing out trace messages as mouseEntered/ mouseExited messages are received. So, the problem also exists with no particular drop-target code implemented (i.e. "just passing/no parking" w.r.t. the tracking area).

-- lwe


_______________________________________________

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


  • Follow-Ups:
    • Re: Odd interaction of NSTrackingArea behaviour with drag and drop
      • From: Luke Evans <email@hidden>
  • Prev by Date: Re: What is using up so much memory here?
  • Next by Date: Re: Background Process?
  • Previous by thread: Re: What is using up so much memory here?
  • Next by thread: Re: Odd interaction of NSTrackingArea behaviour with drag and drop
  • Index(es):
    • Date
    • Thread