Fix missing paths when items dropped from archive

[jiejasonliu]

Grab all paths from DROPFILES struct provided in drag event data

GetStorageItemsAsync() only giving up to 16 items when items are dropped from any archives

• When this occurs, we should look into FileDrop key for a stream of the DROPFILES struct
• This struct contains a null-character delimited string of paths which we can just read out

Validation Steps Performed

• Unit tests pass locally
• Drag and drop paths work for both archives and non-archives files, folders, shortcuts, etc.

Closes #14628

[jiejasonliu]

@microsoft-github-policy-service agree

[zadjii-msft]

I mean, I see how this works, but is there any documentation on this? It seems like ~ m a g i c ~ that getting the "FileDrop" out of a DataPackageView just so happens to have the value of a HDROP embedded in the stream. It's just crazy.

Though, https://learn.microsoft.com/en-us/uwp/api/Windows.ApplicationModel.DataTransfer.StandardDataFormats?view=winrt-22621 does list a bunch of other magic strings that seem to return HGLOBALs, so I'm not doubting it, I'd just like to have an official reference to point to.

[jiejasonliu]

I mean, I see how this works, but is there any documentation on this?

I totally get that and I'll try my best to compile all the resources I've used.
Admittedly, I can't give you exact answers since a lot of things are closed source.
It really came down to relying on older references and anticipating backward compatibility was kept.

just so happens to have the value of a HDROP

My initial discovery was looking through the data package's AvailableFormats property.

Upon finding FileDrop, I dug into the .NET reference source and found this line of code where the callee stores it in an HDROP format. So yes, an HDROP embedded directly in the stream!

Then combining these (one) (two) sources, I was able to successfully parse the file paths out.
Technically, you could manually parse them, but the intrinsic DragQueryFile does exactly that for you.

[carlos-zamora]

Looks great! Just sprinkled a few const throughout. Thanks!

[carlos-zamora]

@msftbot merge this in 20 minutes

[ghost]

Hello @carlos-zamora!

Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:

• I won't merge this pull request until after the UTC date Tue, 10 Jan 2023 23:03:31 GMT, which is in 20 minutes

If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you".

[carlos-zamora]

Extracted from PR body:

Attachments

Terminal-14628-before.mp4

Terminal-14628-after.mp4

[DHowett]

Few style notes, otherwise: Thanks so much for doing this!

[ghost]

Hello @DHowett!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

Do note that I've been instructed to only help merge pull requests of this repository that have been opened for at least 8 hours, a condition that will be fulfilled in about -3619 seconds. No worries though, I will be back when the time is right! 😉

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[DHowett]

I had one last drive-by change, as I'd checked the code out to verify my casts/emplaces worked, to reduce another copy. Opportunistic, not required :)

Marked for automatic merge and servicing to 1.16. Thanks again!

[ghost]

🎉Windows Terminal v1.16.1023 (10231 and 10232) has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉Windows Terminal Preview v1.17.1023 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download