I know how to associate a file type with an app and have a file dropped onto the app’s icon cause the app to launch and open the file. But…
Is there a way to be able to drop multiple files of the same type onto the App’s icon and have the app launch and load all of the files? The App.OpenDocument event handler only works with a single folderitem and there is no guarantee that the files I need to drop are in a folder
The OpenDocument event will fire once for each document dropped.
NextItem is your best friend in that case (in conjunction with a loop …)
https://documentation.xojo.com/api/user_interface/desktop/dragitem.html#dragitem-nextitem
@Emile_Schwarz
You don’t get a dragitem in OpenDocument. The event passes you a folderitem. As Matt said, the event will fire once per file.
And if you need to collect them together, you have two main paths:
1: in OpenDocument, add each folderitem to an array (property of the app class) and start a timer object with a short period. In the Timer’s action method (use delegate to catch the event), use the array and reset it to empty.
2: in HandleAppleEvent (Mac only), catch the event whose class is “aevt” and type is “odoc”. Its main parameter contains the list of files straight there (using TheEvent.DescListParam(“----”)).
I searched in the documentation, but failed.
The nearest document found is:
http://documentation.xojo.com/topics/user_interface/desktop/supporting_drag_and_drop.html
but this is not what the OP asked (but the title suggested it was the correct document).
A link to the correct document is welcome.
that’s how I’ve done it for decades
You know “Drop” means a lot of things in English, right? 
Drag&Drop is an action made to controls (the page you found).
Dropping to the Dock happens outside of Xojo, before you get an event, and results in the same action as opening a document; therefore, the action of dropping is irrelevant in that case (as far as Xojo is concerned), even if the original action contains the word “drop” 
Xojo’s behaviour is a bit weird, IMO. Under the hood, it receives that AppleEvent and, by iterating thru it, sends an OpenDocument event for each item. It’s then up to us to either shortcut that by either handling the AppleEvent earlier (in HandleAppleEvent) or “redo the iteration” with the Windows-compatible method of adding items in an array and then using the array.
If it was the other way around (OpenDocument having an array of all items at once), replicating the current behaviour would be trivial (iterate ourself in code; done), so probably better in most situations.
A weakness, IMO.
If OpenDocument fired once with an array it would be up to us to handle opening multiple documents. As it’s currently designed, you can expect and design OpenDocument to handle one document and then if the user wishes to open multiple it’s already handled. In my opinion, it’s easier this way - I don’t even handle the AppleEvent… (see VersionTracker)
Think TextEdit, where each document is a window. Not Preview where they all get collected into one window.
It’s a bummer that to create something like Preview where the documents get collected into one window that you’ll have to do some extra work. But as I see it, the current design isn’t a weakness, bug, or flaw.
The reason we did that is for consistency between platforms.
Yes, probably easier that way.
My point was it’s easier for us to get an array and loop thru it (TextEdit mode) than to get each item from the event and make an array to use (Preview mode).
Approaches for the latter case aren’t perfect. For example, if there’s a delay before the last item gets processed (application hanging, waiting for CD reading, etc.) and the user, in the meantime, drops a list of other files to the Dock, the app would receive all the files (first and second sets) in a row and knowing where both sets split can’t be done.
I agree this is an edge case, but with the other way around, it would always work, and is also less reliable that way.
Valid reason, true. And with the possibility to handle the Mac AppleEvent, it’s the best of both worlds.
But does Windows really can’t pass several files at once when opening files that way? Isn’t the OS passing an array of paths like when we provide a console app/command line script a list of files?
Thanks, all. The piece I was missing was that OpenDocument fired for each dropped file. Thanks, Matthew.
As Arnaud suggested, I’m having the OpenDocument build a FolderItem array. Then, later, the appropriate method in the main window pulls the folderitems from that array and processes them. It also helps simplify my code since, with the files not being processed in the App object, I can use the same processing method(s) for files dropped on the app’s icon or on the window’s listbox.