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

Things you’d like to miss in the future...
perceuze
Posts: 6
Joined: 10 Dec 2017 13:00

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

Postby perceuze » 10 Dec 2017 13:39

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
Posts: 6470
Joined: 06 Feb 2011 00:33

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

Postby highend » 10 Dec 2017 16:45

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
One of my scripts helped you out? Please donate via Paypal or highend (at) web (dot) de

admin
Site Admin
Posts: 43294
Joined: 22 May 2004 16:48
Location: Cologne, Win 8.1
Contact:

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

Postby admin » 11 Dec 2017 11:00

perceuze wrote: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? :eh:

perceuze wrote: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
Posts: 6
Joined: 10 Dec 2017 13:00

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

Postby perceuze » 11 Dec 2017 11:29

highend wrote:Configuration | General | Sort and Rename | Sort | Keep folders on top


So obvious, thanks!

admin wrote: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? :eh:


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.

admin wrote: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
Posts: 6470
Joined: 06 Feb 2011 00:33

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

Postby highend » 11 Dec 2017 11:42

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...
One of my scripts helped you out? Please donate via Paypal or highend (at) web (dot) de

admin
Site Admin
Posts: 43294
Joined: 22 May 2004 16:48
Location: Cologne, Win 8.1
Contact:

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

Postby admin » 11 Dec 2017 11:45

perceuze wrote: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
Site Admin
Posts: 43294
Joined: 22 May 2004 16:48
Location: Cologne, Win 8.1
Contact:

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

Postby admin » 11 Dec 2017 11:49

perceuze wrote:
admin wrote: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. :eh:

jupe
Posts: 92
Joined: 20 Oct 2017 21:14

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

Postby jupe » 11 Dec 2017 11:56

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 :D, here is some info explaining it

https://stackoverflow.com/questions/39612616/drag-and-drop-from-32-to-64-bit

perceuze
Posts: 6
Joined: 10 Dec 2017 13:00

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

Postby perceuze » 11 Dec 2017 12:19

admin wrote: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. :(


Does this imply you do not have control over its source code?

admin
Site Admin
Posts: 43294
Joined: 22 May 2004 16:48
Location: Cologne, Win 8.1
Contact:

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

Postby admin » 11 Dec 2017 12:23

jupe wrote: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 :D, here is some info explaining it

https://stackoverflow.com/questions/39612616/drag-and-drop-from-32-to-64-bit

Wow, interesting!

admin
Site Admin
Posts: 43294
Joined: 22 May 2004 16:48
Location: Cologne, Win 8.1
Contact:

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

Postby admin » 11 Dec 2017 12:24

perceuze wrote:Does this imply you do not have control over its source code?

Yep. It bugs me, but I have no means here to do this myself.

perceuze
Posts: 6
Joined: 10 Dec 2017 13:00

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

Postby perceuze » 11 Dec 2017 13:24

admin wrote:Yep. It bugs me, but I have no means here to do this myself.


Well, I unchecked the 64-bit option and it works as expected. Unfortunately I need it enabled because of a 64bit-only extension I cannot get rid off, which also means the Shift key must taken into account in this particular case despite the partial solutions offered by @highend and @jupe.

That makes of those issues blocking ones to my use case so definitely a deal breaker. However it's been a couple of days I'm trying XYplorer and it seems I would be a happy user otherwise. Thus, as a C++ developer, I'm willing to offer you to write a drop-in replacement of ContextMenu64.exe if you would accept the following conditions:

  • For the sake of maintainability and trust, I would publish the source code of this replacement under the terms of a permissive open source license. Typically MIT, BSD, or zLib, but not GPL or similar
  • You would grant me a "Lifetime License Pro" of XYplorer

This would of course create a partnership based on trust. Does it sound like an acceptable deal to you?

admin
Site Admin
Posts: 43294
Joined: 22 May 2004 16:48
Location: Cologne, Win 8.1
Contact:

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

Postby admin » 11 Dec 2017 13:32

perceuze wrote:
admin wrote:Yep. It bugs me, but I have no means here to do this myself.


Well, I unchecked the 64-bit option and it works as expected. Unfortunately I need it enabled because of a 64bit-only extension I cannot get rid off, which also means the Shift key must taken into account in this particular case despite the partial solutions offered by @highend and @jupe.

That makes of those issues blocking ones to my use case so definitely a deal breaker. However it's been a couple of days I'm trying XYplorer and it seems I would be a happy user otherwise. Thus, as a C++ developer, I'm willing to offer you to write a drop-in replacement of ContextMenu64.exe if you would accept the following conditions:

  • For the sake of maintainability and trust, I would publish the source code of this replacement under the terms of a permissive open source license. Typically MIT, BSD, or zLib, but not GPL or similar
  • You would grant me a "Lifetime License Pro" of XYplorer

This would of course create a relationship based on trust. Does it sound like an acceptable deal to you?

Absolutely! Sounds great to me, it's a deal. :tup:

I will send you the (few) specifications (e.g. input format) of the current ContextMenu64.exe file by email later today.

admin
Site Admin
Posts: 43294
Joined: 22 May 2004 16:48
Location: Cologne, Win 8.1
Contact:

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

Postby admin » 11 Dec 2017 15:02

I can post the specifications right here:

- "ContextMenu64.exe" is a 64-bit executable.
You should probably choose a different name for yours, so we can keep the two approaches separate.
- Description: "64-bit Context Menu Helper"
- Would be cool if it had the same/similar icon as XYplorer.exe (I can send the ICO file if needed).
- The data are sent by command line parameter. The command line parameter is the
full path (in double-quotes) to a text file located in the user's TEMP folder.
This file contains the data proper. So you have to open this file and parse its
contents.
- This file is encoded in UTF-16LE in order to handle Unicode filenames.

- The data are only two things:
1) the position of the menu (X and Y)
2) the item(s) for which to create the shell context menu
- the current format (of course, you may suggest improvements to the format!) is (example):
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
||PosX=200 PosY=100
C:\Test\Image 01.jpg
C:\Test\Image 02.jpg
C:\Test\Image 03.jpg
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- first line starts with || (two empty fields reserved for whatever; I admit
I'm not sure now what the idea had been...)
then PosX=[value][space]PosY=[value]
the values are absolute screen positions
- the subsequent lines contain the item(s), one per line
- each item is simply the full path
- In case of virtual folders (Computer, Network, Recycle Bin...) the CLSID
is passed in this format (here Recycle Bin):
::{645FF040-5081-101B-9F08-00AA002F954E}

- The "Rename" item should be suppressed in the menu, since this would require a
callback to XYplorer.exe. Could be done but I'd like to spend my time better.
And who needs a rename here anyway? Rename is F2, period. :)

- You don't need to close the file when the menu is hidden after use. XYplorer
will close it on exit by passing the command line "-quit" (without the quotes)
to "ContextMenu64.exe".
- So you also have to process "-quit" by shutting down your app.

Well, that should be it.

Thanks again,
Don

perceuze
Posts: 6
Joined: 10 Dec 2017 13:00

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

Postby perceuze » 11 Dec 2017 16:43

Since we can break backward compatibility...

"XYmenu64.exe" then? So that it follows the naming of the other executables.

It will be fully compatible with the UNICODE implementation of the Windows API.

Regarding the parsing of the parameters I would adopt a more standard and evolutive approach to allow further changes to the way parameters are passed in the future without having to (potentially) break compatibility.

According to this and what you provided, specification would be roughly as follows:

Code: Select all

XYmenu64.exe [options] [file] ...

Options:
  --mouse <XxY>
    Mouse coordinates
  --datafile <path>
    The text file to read the [file] args from.
    One file/shell item per line
  --quit
    Quit.

Examples:
  XYmenu64.exe --mouse 123x40 C:\dir\file.txt ::{645FF040-5081-101B-9F08-00AA002F954E}
  XYmenu64.exe C:\dir\some_file.DLL
  XYmenu64.exe --datafile C:\Users\Bob\AppData\Local\Temp\UniqueName.txt
  XYmenu64.exe --mouse 1x2 --datafile C:\Users\Bob\AppData\Local\Temp\UniqueName.txt


Mouse position is declared as optional because, from the top of my head, it is not a technical requirement. But I guess it is still useful to pass it so that the menu pops up at the exact initial position in case user moved the mouse a bit while XYmenu64 is invoked (spawning a process is heavy after all). If specified, it would always be via the command line (i.e. instead of the temp file).

To avoid the heaviness and ugliness of creating a temporary file when it is not necessary (i.e. max limit of command line not exceeded; so most cases a priori), I suggest XYplorer to pass all the arguments via the command line so that any remaining positional argument is interpreted as a file/shell address.
Otherwise, would the max limit be reached (least common case a priori), it would still be able to use the "--datafile" parameter.

To avoid any trouble on both sides, the whole command line will be passed by XYmenu64 to the CommandLineToArgvW API instead of implementing a custom parser. But I trust XYplorer already follows the conventional guidelines to quote the command line instead of just adding double-quotes :)


Return to “Bug Reports”



Who is online

Users browsing this forum: No registered users and 1 guest