Recent

Author Topic: Drag and Drop Files; onDropFiles "locks" Finder's Drag and Drop abilities  (Read 576 times)

Hansaplast

  • Hero Member
  • *****
  • Posts: 762
  • Tweaking4All.com
    • Tweaking4All
Not sure if this is expected behavior, or a bug.
If expected behavior, then can anyone tell me what I should be doing or what I'm doing wrong.

I have an application that takes files with Drag and Drop from the Finder (same effect occurs with other Filemanagers like Forklift and PathFinder as well).
As long as the onDropFiles event has not been completed, drag and drop in Finder will not work properly, for example when a large number of files is being processed in the onDropFiles, making Finder unusable until the event has been completed.

This can be demonstrated with a simple example:

Code: Pascal  [Select][+][-]
  1. unit Unit1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. interface
  6.  
  7. uses
  8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls;
  9.  
  10. type
  11.   { TForm1 }
  12.  
  13.   TForm1 = class(TForm)
  14.     procedure FormDropFiles(Sender: TObject; const FileNames: array of string);
  15.   private
  16.   public
  17.   end;
  18.  
  19. var
  20.   Form1: TForm1;
  21.  
  22. implementation
  23.  
  24. {$R *.lfm}
  25.  
  26. { TForm1 }
  27.  
  28. procedure TForm1.FormDropFiles(Sender: TObject; const FileNames: array of string);
  29. begin
  30.   ShowMessage('temporary "lock" FormDropFiles');
  31. end;
  32.  
  33. end.
 

Attached an example screen recording, hopefully this helps clarifying what I'm running into.
While the onDropFiles event is running, selecting a file in Finder and dragging it will cause everything to be selected the mouse moves over.
Once the onDropFiles event is completed, drag and drop in Finder works normal again.
Both can be seen in the screen recording.

Could it be that concludeDragOperation (DraggingDestination - concludeDragOperation) may need to be called earlier (not knowing what I'm talking about)?
« Last Edit: January 13, 2026, 07:44:20 pm by Hansaplast »

Hansaplast

  • Hero Member
  • *****
  • Posts: 762
  • Tweaking4All.com
    • Tweaking4All
Bug reported: 42001

Would be cool if others could confirm 😊
(not impatient by any means, just happened to be in BugTracker for another issue)

Boleeman

  • Hero Member
  • *****
  • Posts: 1103
I also  noticed that drag and drop behavior with a Win32 compiled Lazarus program, where the GUI seizes up if given multiple Drag and Drop files until the 1st file is processed. Then I made a 64Bit compiled version of the same program, but that seizing behavior seemed to have vanished. Just thought I'd mention my Drag and Drop observations (although I use Windows and not Mac).

Hansaplast

  • Hero Member
  • *****
  • Posts: 762
  • Tweaking4All.com
    • Tweaking4All
Always good to post suggestions 😊


Unfortunately, 32 bit vs 64 bit isn't an issue under macOS, as 32 bit is no longer supported for several years now.
However, did try compiling for different CPU's (Intel and Apple Silicon) and several SDK's - they all show the same issue.


Thank you for chiming in though - it is appreciated.

msintle

  • Sr. Member
  • ****
  • Posts: 373
Not surprised to hear the geniuses at RottenApple had a hard time figuring out how to properly implement drag-drop across applications without blocking.

Sounds like a platform issue to me, that has to do with poor OS design, rather than an actual Lazarus responsibility.

On Windows I've had my own (target) application seem to lock up if it does extensive processing after receiving a drag-and-drop from another application, but never the source application.

Pretty shocked to hear that is the state of things with macOS, but hey, they don't even have uninstallers in the second quarter of the 21st century, so what do you expect?

Hansaplast

  • Hero Member
  • *****
  • Posts: 762
  • Tweaking4All.com
    • Tweaking4All
Not really helpful in solving the issue at hand.

One can argue this either way:
Is the correct way, or the wrong way, to deal with Drag and Drop ...
I suppose it depends on what the application is supposed to do with the drag and drop action and if it is correct to have the source wait for the dealings with the files are completed or not. I guess that would be up to the developer to decide.
There is a way to release the drag and drop, wether we implement it that way or is up to the team to decide.
For now I have found a workaround.

msintle

  • Sr. Member
  • ****
  • Posts: 373
My point is, it's just bad design and/or implementation if you're letting one potentially misbehaving application lock up other applications on the system.

That's why applications have had separate memory spaces for three and a half decades, for example, so memory corruption in one application doesn't bring down the whole system.

But yes, leave it to RottenApple to regress the state-of-the-art in computing ;)

 

TinyPortal © 2005-2018