The drop source is blocked, when a file is dropped on SciTE until it loads it.
Early releasing the drag handle the drop source is responsive soon.
This is especially needed for large files, when the opening takes noticeable amount of time.
Sample implementation, see SCITE_DROP
Looks to me like a minor issue with a heavy maintenance cost in terms of complexity. Pointers are posted as messages and may leak with multiple in-transit.
Don't you avoid source blockage by calling ::DragFinish before any Open()s?
I tested it again, calling ::DragFinish is not sufficient. The WM_DROP message callback must be returned.
Try to add Sleep(5000) in the message handler.
It seem it has to do with focus switching by the window manager.
You are right with multiple transits though.
dropFilesArray should just be a std::queue of GUI::gui_string with DropFiles adding to the queue and SCITE_DROP popping them and opening the files.
new patch with deque
I have changed the implementation as suggested, at time of my original implementation using c++ std lib in SciTE was rare.
Since pathDropped is an array of 2 byte characters and the third argument to DragQueryFile is number of characters, not bytes, sizeof can't be used as it says the buffer is twice as large as it really is.
Committed for drop files case but not including paste files. Minor edits like changing name dropFilesBuffer to dropFilesQueue.