[Bug] Ctrl/Shift+Drag & Drop to Explorer Not Working as Expected.

[JTB3]

Hi David,
I'm using the latest v1.4.1.935-x64 installed on W10 v1809 and I'm having issues when using modified (Ctrl+Drag & Drop) or (Shift+Drag & Drop) actions to either move or copy files from the Everything app window to an open Windows Explorer folder or the Desktop. Here are my reproducible actions and observations:

• If I press the Ctrl (Copy) or Shift (Move) modifier BEFOREHAND and drag the file to an explorer folder, everything works as expected (Great!).

• However, If one 1st starts the drag operation (with no Ctrl or Shift modifier key pressed) and THEN presses the Ctrl (Copy) modifier and finishes dragging the file to the explorer folder, the file is instantly MOVED as soon as the Ctrl key is pressed down.
  (This is an issue because: A) the normal Windows Explorer behavior is to do NOTHING until one releases the Left-Mouse Button, AND B: The File should be COPIED - NOT MOVED!).

• Also, If one 1st starts the drag operation (with no Ctrl or Shift modifier key pressed) and THEN presses the Shift (Move) modifier and finishes dragging the file to the explorer folder, the file is instantly MOVED as soon as the SHIFT key is pressed down.
  (This is an issue because the normal Windows Explorer behavior is to do NOTHING until I release the Left-Mouse Button).

These last 2 above Drag & Drop situations are frustratingly producing unexpected/inconsistent Copy+Move behaviors from Everything, which interrupts one's workflow and forces one to undo these unwanted file MOVES by pressing Ctrl-Z and then use a workaround (by pressing the Ctrl modifier beforehand).

I'm not sure when exactly this broken behavior got introduced, but can you please fix this inconsistency and make Everything Drag & Drop files (with the Ctrl and Shift modifiers) like Windows Explorer?

Thanks in advance for your response! -JT

[void]

Thanks for the bug report.

However, If one 1st starts the drag operation (with no Ctrl or Shift modifier key pressed) and THEN presses the Ctrl (Copy) modifier and finishes dragging the file to the explorer folder, the file is instantly MOVED as soon as the Ctrl key is pressed down.

Pressing Ctrl finishes the drag drop operation?

I have not managed to reproduce the issue here on Windows 10 1809 x64 with Everything 1.4.1.935.

Am I missing a step?

Everything does track the mouse button, if you start the drag with the left button, pressing the right button will cancel the drag operation (and vice versa). Releasing the initial mouse button will execute the drop operation. Everything does not track the Shift or Ctrl key, this is done by the drag drop target (ie: Windows Explorer - more specifically the IDropTarget interface for the shell item you dropped the file on).
Not to say this isn't an issue with Everything..
This only happens when you drag from Everything? ie dragging from Windows Explorer is OK?
Is pressing Ctrl or Shift somehow faking a mouse button press/release?

Do you have any third party software that might be implementing some sort of IDropTarget wrapper?

Debug logs may shed some light on the issue:

• In Everything, type in the following search and press ENTER:
  /debug

What is shown in debug console after you start a drag drop operation from Everything and press CTRL while in Windows Explorer?

To close the debug console:

• In Everything, type in the following search and press ENTER:
  /debug

[JTB3]

Thanks for your fast response, David! (for some reason I didn't get notified of it, so I'm just seeing it now)

As it turns out, it WAS a 3rd-party 'X-Mouse Button Control' software utility (specifically a custom 'Button Chording' script) that was causing the interference/issue. After tweaking the script I was able to restore the original (perfectly working) behavior in Everything.

More kudos for all your hard work and excellence with Everything!
(Looking forward to you implementing an Everything 'Dark Mode' in a future version to match the new W10 v1809 dark File Explorer!)

Cheers, -JT