| What version of Mac OS X? There is a bug in Finder 10.4.x where Finder could sometimes start 2 drags (that's actually the bug I was referring to below, but I didn't realize you were dragging from Finder). It's not something that very many users reported, but under just the right timing conditions it can be fairly reproducible.
To confirm that you're seeing the Finder bug, try this: View > as List, and see if you can still repro the problem. List view does not have the problem. (And it's fixed for the other views in Leopard.)
Cheers,
On Oct 30, 2007, at 2:36 AM, Yaron Tadmor wrote: I’m dragging a file from the Finder, so I have no control over the code initiating the dragging. I’m just handling the track and receive in my app.
From: David A. Lyons [mailto:email@hidden]
Sent: Tuesday, October 30, 2007 11:23 AM
To: Yaron Tadmor; carbon-dev List
Cc: Bryan Prusha
Subject: Re: drag manager strange behavior Where are you dragging from? Do you control the code that calls TrackDrag? If so, check if it's being called twice. I have seen a situation where a Carbon application was creating+tracking a drag in response to a kEventMouseDragged Carbon event. This event means "the mouse moved while the button was down." It turned out to be perfectly possible to receive more than one kEventMouseDragged event even if the application called TrackDrag in response to the first one. The solution was to add a small amount of logic so that following each kEventMouseDown for our view, we would only start a drag in response to one kEventMouseDragged. --Dave On Oct 30, 2007, at 1:18 AM, Yaron Tadmor wrote:
Checking what you asked I see a second drag reference is created. This is the print out from the start and end of the drag track and receive handlers: track handler: 0x58000000 track handler: 0x58000000 recieve handler: 0x58000000 track handler: 0x58000000 track handler: 0x58000000 track handler: 0x5c000000 track handler: 0x5c000000 track handler: 0x5c000000 track handler: 0x5c000000 recieve handler: 0x5c000000 track handler: 0x5c000000 track handler: 0x5c000000 This seems like a Carbon bug to me. Does the DragRef have the same value for both sets of receive calls? Perhaps a second drag is being accidentally created after the first drop. It would be interesting if you could identify the full backtraces for the receive calls. On Oct 23, 2007, at 10:05 AM, Yaron Tadmor wrote: Hi, I installed a track and a receive handler for drag and drop support. The track handler simply redraws some part of the window to let the user know where the drag is going to fall, and returns noErr. The receive handler loads the image from a file that was dragged and adds it to the window, then returns noErr (an error is returned if it’s not an image file). In most situations the drag works perfectly fine. However, when the track handler takes a little more time, a strange thing happens. My receive handler gets called twice! Tracing the code I added printouts in both track and receive handlers start and end, and I get the following print: … enter track end track enter track end track enter receive end receive enter track end track enter track end track enter receive end receive enter track end track enter track end track I’m not really sure what is going on, but it seems like when the release happens while in the track functions, I get 2 calls to receive. Is this a known issue? Has anyone seen this? Thanx Yaron Tadmor
|
