Does this imply you do not have control over its source code?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.
New ContextMenu64.exe
New ContextMenu64.exe
-
- Site Admin
- Posts: 60567
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: New ContextMenu64.exe
Yep. It bugs me, but I have no means here to do this myself.perceuze wrote:Does this imply you do not have control over its source code?
FAQ | XY News RSS | XY Twitter
Re: New ContextMenu64.exe
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.admin wrote:Yep. It bugs me, but I have no means here to do this myself.
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
-
- Site Admin
- Posts: 60567
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: New ContextMenu64.exe
Absolutely! Sounds great to me, it's a deal.perceuze wrote: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.admin wrote:Yep. It bugs me, but I have no means here to do this myself.
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:
This would of course create a relationship based on trust. Does it sound like an acceptable deal to you?
- 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
I will send you the (few) specifications (e.g. input format) of the current ContextMenu64.exe file by email later today.
FAQ | XY News RSS | XY Twitter
-
- Site Admin
- Posts: 60567
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: New ContextMenu64.exe
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
FAQ | XY News RSS | XY Twitter
Re: New ContextMenu64.exe
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:
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
"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
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
Re: New ContextMenu64.exe
Would you be so kind to send me your e-mail address so that we can pursue this without polluting the forum?admin wrote:Looks good!
I suspect an exchange will be required for the technical details and the tests.
Re: New ContextMenu64.exe
One of my scripts helped you out? Please donate via Paypal
-
- Site Admin
- Posts: 60567
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: New ContextMenu64.exe
Good news: Next version the 64-bit context menu will support the SHIFT key to pop the "extended" menu!
Thanks to Daniel, the author of ContextMenu64.exe, who found the time to add this within a very short time.
Thanks to Daniel, the author of ContextMenu64.exe, who found the time to add this within a very short time.
FAQ | XY News RSS | XY Twitter
Re: New ContextMenu64.exe
The source code of the app was (already) / will be published?
One of my scripts helped you out? Please donate via Paypal
Re: New ContextMenu64.exe
I think highend remembered:admin wrote:Not that I know of.
But, at least, I hope you have the source, now?perceuze wrote:
- 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
Edit forgot to say "happy new year to all"!!
Win11 Pro 223H2 Gerrman
Re: New ContextMenu64.exe
Splitted these postings from the original thread to better keep track of this change...
One of my scripts helped you out? Please donate via Paypal