Cocoa Drag & Drop from Finder - Snap Back

I have a canvas which accepts dropped folders, and recursively processes these. I’m finding that in Cocoa builds, about 10 seconds after the dropObject event has happened, the Finder does an animation which appears to “snap back” the files. I’m guessing this is an indication from the OS that “the dropped files were not accepted”?

Since my file process step takes 10s of seconds, I thought perhaps I should let the DropObject event return and process the files on a timer callback : this doesn’t seem to make a difference.

Is there something I’m doing wrong?

I use the timer callback method to successfully handle files dropped from the Finder in Cocoa. Maybe showing a bit of your code would help.

I was getting the same problem. My app parses large statement files, thousands of transactions. I was parsing in the main thread meaning the interface was locked until the parsing completed, I was getting the same effect, the dropped file appeared to snap back into finder. I am now parsing in a thread so the main thread is not locked and the interface is still active while the parsing happens in the background, this has stopped the snap back of the dropped file.

I suspect what is happening is that when you drop the file, in the background the file source (i.e. Finder) is being told the file drop is accepted. If your app is busy processing your dropped file the main thread is not communicating back that the drop was accepted so finder animates a snap back.

My advice, process your folders in a thread and this should stop this issue. Let me know.

Thanks Mike & Jonathan

  • In the prior version of my App, I was doing the heavy computation in the Canvas.DropObject event - this caused the finder “snap back” behavior.
  • in the new version of my app, I do the heavy computation on a timer, which is launched within the Canvas.DropObject event - so the dropObject event returns nearly instantaneously. However, I still see the “snap back issue”.

It sounds as if the OS is sending another notification to the app (perhaps an AppleEvent?) and since my app is busy processing the file drop in the Timer.Action callback, the OS never sees a reply?

If the solution is to process the files in a Thread rather than a Timer, I can do that, but I wan’t to make sure that’s the solution before I go re-engineering my app :slight_smile:

This seems like you’re doing the right thing. Can you file a bug report so that I can look into it?

Disable the timer callback and see if you still get the “snapback”. If no snapback occurs then your hypothesis is correct.

Regardless, heavy operations should always be run in a thread to keep the interface responsive.

Here’s how I’d handle it:

  1. File Drop occurs; add the files to a queue
  2. Check if the queue is currently being processed, if not then start the thread which does the processing
  3. Tell the system you’ve accepted the file drop
  4. Use a timer to update progress indicators in the UI while the thread is doing the processing.

Further information that I’ve witnessed. Once I accept the drop (from Finder), there’s no processing that takes place and still I get a 10 second delay. My app once the drop occurs invokes a dialog based on receiving the folder (or file) location from the drag and drop. I know you all are suggesting to process in a thread, but other than the display of the dialog there’s nothing going on in my app! Until the snap back occurs, I can’t even enter text in the dialog.

Yikes! I’ll try this on Windows too and report back. (I think that I’ve seen similar behavior before…)


Seeing the same behaviour in the IDE when dropping files onto the navigator.

I found that setting the timer period to 100 seemed to solve it for us. All of our apps use Drag & Drop, I personally think having to use a timer is a kludge, but I understand that it must be done this way.

Thomas’ suggestion is also the approach we take for some of the apps, stack up files to be processed.

I verified (at least with my app) that there’s no issue on Windows. I wish there was something that could be done within the Xojo runtime than set up timers/threads to handle it. I do think I’m going to get customer frustration out of this!

PS - Sam, I went ahead and bought your App Packager Mini on MAS. I can’t wait to try it!

What files are you dropping into to the application? Do you have ‘accept picture drop’ enabled? I seem to recall that allowing a picture drop caused some issues a while ago, but I don’t recall exactly or if it’s been fixed.

Let me know if you have any questions about AWM, otherwise I hope you have fun.