Shift+RMB and Drag'n'Drop to external app

[perceuze]

Hi! New trial user here, I noticed a couple of bugs/features:

• Shift+RMB does not invoke the extended Shell menu regardless of the location of the click (tree, list, white) or the location/type of the target file. Did I miss an option?
• Drag'n'Drop operations to external apps do not seem to work, regardless of the location/type of file. A text file dragged to a non-elevated Notepad for example reproduces this every time

Bonus question, is there a way to always keep the folders first in the list view, regardless of the sorting (modification date here)?

Remarks:

• Windows 8.1 64-bit
• XYplorer 18.50.0300, not elevated
• "Show the 64-bit context menu" option is enabled
• Only one tweak applied:

  Code: Select all

  CEA_ListRightClickOnWhite=1

There is obviously a lot of work involved in this software so.. Kudos!

[highend]

Drag'n'Drop operations to external apps do not seem to work

After a few tests with different applications this seems to be true for any 64-bit
app, may it be notepad, paint or e.g. a portable Sublime Text x64 version.

But when these apps are started as their 32-bit equivalent, drag & drop to them
works fine.
E.g. try it with "C:\Windows\SysWOW64\notepad.exe" or "C:\Windows\SysWOW64\mspaint.exe"

is there a way to always keep the folders first in the list view, regardless of the sorting (modification date here)?

Configuration | General | Sort and Rename | Sort | Keep folders on top

[admin]

Shift+RMB does not invoke the extended Shell menu regardless of the location of the click (tree, list, white) or the location/type of the target file. Did I miss an option?

This used to work (in XP I think), but at the moment I indeed fail to see any difference between normal and extended menu. But this is also true in Explorer. Does this extended Shell menu still exist in Win8 and later?

Drag'n'Drop operations to external apps do not seem to work, regardless of the location/type of file. A text file dragged to a non-elevated Notepad for example reproduces this every time

Seems to depend on the target app. I can confirm it does not work with Notepad (64 bit), but it does work e.g. with EmEditor (64 bit). This is tough to fix and hard to understand. What is difficult about receiving a dropped file?

Anyway. welcome to the club!

Don

[perceuze]

Configuration | General | Sort and Rename | Sort | Keep folders on top

So obvious, thanks!

This used to work (in XP I think), but at the moment I indeed fail to see any difference between normal and extended menu. But this is also true in Explorer. Does this extended Shell menu still exist in Win8 and later?

Not only Windows itself but some Shell extensions as well like the ones registered by TortoiseSVN and TortoiseGit for instance.
It also depends on the type of the file, an .exe file seems to be a good target for your tests so that you don't have to install a Shell extension to check the difference.

Seems to depend on the target app. I can confirm it does not work with Notepad (64 bit), but it does work e.g. with EmEditor (64 bit). This is tough to fix and hard to understand. What is difficult about receiving a dropped file?

Perhaps a FORMATETC or CLIPFORMAT mismatch (or equivalent in Basic)? That is, target app expects/requires a specific FORMATETC/CLIPFORMAT (wrongly or not) whereas XYplorer provides another(s) (wrongly or not). For instance, I've seen a lot of trouble in the past due to CF_TEXT vs. CF_UNICODETEXT during the ANSI to UNICODE transition period.

[highend]

Shift+RMB does not invoke the extended Shell menu regardless of the location of the click (tree, list, white) or the location/type of the target file. Did I miss an option?

The problem is your setting:

Code: Select all

"Show the 64-bit context menu" option is enabled

This invokes an external app "ContextMenu64.exe" in the XY folder,
which does not support these extended entries.

Only way to solve this currently:
Disable "Show the 64-bit context menu" and when you really need
it, choose "Show 64-bit Context Menu" from the normal context menu...

[admin]

Not only Windows itself but some Shell extensions as well like the ones registered by TortoiseSVN and TortoiseGit for instance.
It also depends on the type of the file, an .exe file seems to be a good target for your tests so that you don't have to install a Shell extension to check the difference.

Yes, confirmed with an EXE file. But it looks like it works fine with the 32-bit context menu. What not works is the 64-bit menu, i.e. when you ticked this:
Configuration | Shell Integration | 64-bit Windows | Show the 64-bit context menu

Practical problem is that this menu has been written not by me, but by another guy, and he kind of vanished. It's the file ContextMenu64.exe: Roughly it receives one or more filenames and pops the matching shell context menu. Looks like it does not support the held SHIFT key.

[admin]

Seems to depend on the target app. I can confirm it does not work with Notepad (64 bit), but it does work e.g. with EmEditor (64 bit). This is tough to fix and hard to understand. What is difficult about receiving a dropped file?

Perhaps a FORMATETC or CLIPFORMAT mismatch (or equivalent in Basic)? That is, target app expects/requires a specific FORMATETC/CLIPFORMAT (wrongly or not) whereas XYplorer provides another(s) (wrongly or not). For instance, I've seen a lot of trouble in the past due to CF_TEXT vs. CF_UNICODETEXT during the ANSI to UNICODE transition period.

Yes, something like that has to be it (but all the obvious things are alright else dropping would not work at all), but it even if I let the shell create that stuff (Configuration | Shell Integration | Drag and Drop | Use standard shell drag and drop) it does not work for Notepad. Hm.

[jupe]

I always have my 64-Bit context menu disabled and just invoke it with Ctrl+Right click keyboard button when absolutely necessary.

Regarding Drag n Drop, just to add some info on this, I think that the bug isn't in XYplorer its a Windows bug causing it not to work, I had the same problem in my text editor of choice Notepad3 x64 until a build just released last week that included a workaround for the Windows bug, so now thankfully I can drag and drop to it from XY , here is some info explaining it

https://stackoverflow.com/questions/396 ... -to-64-bit

[admin]

I always have my 64-Bit context menu disabled and just invoke it with Ctrl+Right click keyboard button when absolutely necessary.

Regarding Drag n Drop, just to add some info on this, I think that the bug isn't in XYplorer its a Windows bug causing it not to work, I had the same problem in my text editor of choice Notepad3 x64 until a build just released last week that included a workaround for the Windows bug, so now thankfully I can drag and drop to it from XY , here is some info explaining it

https://stackoverflow.com/questions/396 ... -to-64-bit

Wow, interesting!