Support SDL_EVENT_DROP_FILE in Windows with IDropTarget instead of WM_DROPFILES (thanks @Dragon-Baroque!)

[slouken]

This is a tweaked version of #10415, adapted to CoInitialize and OleInitialize() during SDL_VideoInit(), so we know whether OLE functionality is available in advance. This also prevents surprising the application by enabling OLE functionality after video initialization depending on what events are enabled.

From the original PR:
Remove WM_DROPFILES ( supports only SDL_EVENT_DROP_FILE ), use IDropTarget instead ( provides SDL_EVENT_DROP_POSITION, SDL_EVENT_DROP_FILE and SDL_EVENT_DROP_TEXT ).

Description

In src/video/windows/SDL_windowswindow.c + .h,
Create IDropTarget and issue SDL_SendDropPosition,
Handle text/uri-list for SDL_SendDropFile, text/plain;charset=utf-8 and CF_UNICODE_TEXT and CF_TEXT for SDL_SendDropText, CF_HDROP for SDL_SendDropFile.

[slouken]

@Dragon-Baroque, can you take a look at this?

[edo9300]

Imho rather than doing the various pDataObject->lpVtbl->QueryGetData(pDataObject, &fetc) calls, it would be better to rely entirely on the EnumFormatEtc output, as it will also return exactly the clipboard format structures available on the interface.
The most appropriate among the provided formats can then be manually picked and parsed.

[Dragon-Baroque]

Thank you, this is very nice.

I have pushed a rebased replacement of my sdl3-droptext-windows which is exactly your code, except for a few SDL_LogDebug messages :

• Mention the WindowID in some existing messages, at least one per entered callback,
• Add three messages in WIN_AcceptDragAndDrop to log the Drag and Drop enablement / disablement + the choice OLE vs WM_DROPFILES.

[slouken]

Imho rather than doing the various pDataObject->lpVtbl->QueryGetData(pDataObject, &fetc) calls, it would be better to rely entirely on the EnumFormatEtc output, as it will also return exactly the clipboard format structures available on the interface. The most appropriate among the provided formats can then be manually picked and parsed.

Sure, feel free to submit a PR for this.

[Dragon-Baroque]

... The most appropriate among the provided formats can then be manually picked and parsed.

You surely understand that the five QueryGetData are executed in a set order, and since EnumFormatEtc has no reason to return the supported formats in the same order, one would need to scan its entire loop while recording five booleans.
Then use the five booleans to permit each of the five formats.

What would we win ? Undeniably we would avoid calling QueryGetData on a non supported format. I doubt that that service takes more than a few hundreds of instructions to return to me the failure code. Which is negligible in front of the cost of the successful QueryGetData because that one reaches back to the Drag sender to get the Drop data from it.

And to what cost ? An ugly nested if to set the booleans - I cannot use a switch statement, since two of the expected formats are not constants. And then the EnumFormatEtc loop itself. It can fairly be criticized as being useless unless the Logging level of the INPUT category permits the SDL_LogDebug to show. It could easily be fronted with an if on that Logging level. It its purpose is also to record the interesting formats, it could not any more.