Skip to content

Drop files on Explorer tabs as Explorer would, without the interop DLLs - #56

Merged
leafOfTree merged 13 commits into
masterfrom
explorer-drop-without-interop
Oct 10, 2026
Merged

leafOfTree merged 13 commits into
masterfrom
explorer-drop-without-interop

Conversation

@leafOfTree

@leafOfTree leafOfTree commented Oct 10, 2026 •

Copy link
Copy Markdown
Owner

Summary

Dropping files on tabs

  • No interop DLLs. Explorer folders are found late bound through Shell.Application, so Interop.SHDocVw.dll and Interop.Shell32.dll are gone from the repo and the build.
  • Behaves like Explorer. Dropping on a File Explorer tab moves within one drive and copies across drives. Ctrl copies, Shift moves, and files dropped back on their own folder's tab stay put. Right-drag offers the menu again, now in the app's theme.
  • One shell operation, on its own thread. All files go together: one progress dialog, one round of name conflicts, one Ctrl+Z in Explorer to undo, and the tabs stay responsive.
  • A line under the strip says what a drop does, such as "Move to Downloads", in the app's theme. The source's drag image is not shown, as it covered the tabs being aimed at. A tab's window comes forward only once the pointer has rested on it for 300 ms.
  • Names outside the code page. Dropped paths are read through DragQueryFileW. The ANSI entry point turned a name such as 小麦-0.1.24-x64-setup.exe into question marks, so the drop did nothing.
  • Windows 11 Explorer tabs. A drop goes to the folder on show, not the first tab's folder.
  • Explorer refreshes. Open Explorer windows refresh the folders a drop touched.
  • The folder's window keeps the foreground after the progress dialog closes, unless you have moved on to another window.
  • Robustness:
    • Windows are matched by handle before their view is read, so an Explorer view without a folder no longer breaks every drop.
    • The folder is looked up once per hovered tab.
    • Long dropped paths are read in full, and each drop's data is freed.

Other

  • Full titles on hover. Resting on a tab whose title is cut short shows the whole title under the strip, in the app's theme. Title tips stay off open menus.
  • Crash log link. It is offered only when the log holds a crash, and sits apart at the right of the Support links.
  • README. Explains dropping files on tabs, and that Windows blocks drags into apps running as administrator.

Notes

Tests

  • tests/Run-Tests.ps1: all suites pass locally after the rebase. The branch adds checks in Architecture, Reliability and TabInteraction, including reading a dropped path with Chinese characters and moving that file. That check fails without the fix.
  • The Release build (single static exe) and the smoke test run in CI. Locally the Release output was locked by a running WindowTabs.

Each path's buffer is sized to the path instead of 512 characters, and the dropped file list is released after reading.
Explorer folders are found late bound through Shell.Application, so the two interop assemblies are gone. Windows are matched by handle before their view is read, so an Explorer view without a folder no longer breaks every drop. The folder is looked up once per hovered tab instead of on every drag move. Drops can be undone in Explorer, and the source is told the shell did the work, so it cannot act on the files again.
Resting the pointer on a tab whose title is cut by the ellipsis, or hidden beside its icon, shows the whole title under the strip in the app's theme, wrapped past 470px. Moving to another cut title shows it at once; a click, leaving the strip or the strip hiding puts it away.
Within one drive a drop moves, across drives it copies; Ctrl copies, Shift moves, and files dropped back on their own folder's tab stay put. All files go in one shell operation on its own thread: one progress dialog, one round of name conflicts, one step for Ctrl+Z, and the tabs stay responsive. The drag image stays over the strip with a line such as "Move to Downloads", and a tab's window comes forward only once the pointer rests on it for 300 ms.
A Windows 11 Explorer window holds a folder per tab; a drop on its WindowTabs tab now goes to the folder on show instead of the first one. Dropped files also appear and disappear in open Explorer windows at once: the shell's change notices are flushed before the operation's thread ends, where they were lost.
Flushing the shell's queued notices did nothing, as the flush flag cannot stand alone; each folder the operation touched is now told to refresh, delivered before the operation's thread ends.
An emptied WindowTabsCrash.log still showed the Crash log link and opened a blank file; logs without an entry are now passed over, for the link and the tray notice alike.
Files on this PC end the row flush right, apart from the web links on the left, and move to their own line, still at the right, when the row is too narrow.
The progress dialog took the foreground and, closing, could leave it to no window or another app's hidden one, so keys after a drop went nowhere. The folder's window gets it back then; a window the user moved on to keeps it.
The drop recorded the released right button before reading it, so a right-drag moved or copied without asking. The menu is now the themed one the tab menu uses.
…what a drop does

DragQueryFile bound its ANSI entry point, which turned a name such as
小麦-0.1.24-x64-setup.exe into question marks, so the file was not found and the
drop did nothing. The Unicode entry point reads it whole.

The source's drag image covered the tabs being aimed at. A line under the strip,
in the app's theme, now says what letting go does, such as "Move to Downloads".
@leafOfTree
leafOfTree merged commit 2fc798e into master Oct 10, 2026
2 checks passed
@leafOfTree
leafOfTree deleted the explorer-drop-without-interop branch October 10, 2026 04:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant