A few clarifications on the new version

[admin]

- No, there IS communication.
- Clone? XY64contents.exe is NOT identical to XY64ctxmenu.exe, they are totally different.
- I can compile AHK scripts myself. Would you say that using a non-compressed EXE would be notably faster?
- Thanks for the links.

[Antieve]

- Clone? XY64contents.exe is NOT identical to XY64ctxmenu.exe, they are totally different.

Doh... my bad, i decompiled the XY64contents twice

Would you say that using a non-compressed EXE would be notably faster?

No. There will be a gain in time, but negligibly small.
It's better not to use ahk at all.

[admin]

Yes. It's a pity and completely incomprehensible that Windows doesn't offer a simple call to open the context menu. Instead, the code required to do this is voluminous and nightmarish.

[admin]

Code: Select all

DetectHiddenWindows, On
ownHWND := WinExist("Ahk_PID " DllCall("GetCurrentProcessId"))

This stores it's own hwnd...

Okay.... not sure how to make use of this.

[highend]

You could let it return that hwnd so that you'd be able to send data to it via wm_copydata

[admin]

Well, assuming I know AHK

[Antieve]

As I see it, the functionality of window messages is partially implemented in ahk in some kind of form of internal high-level analogues

from XY64ctxmenu.ahk

[highend]

Well, assuming I know AHK

It's not that difficult.

You could start it with XY's hwnd as a parameter and then it can send back it's own hwnd back to XY with wm_copydata (and you receive it on XY's side via receive_wm_copydata).

[admin]

I do it exactly this way with XYcopy.exe, but that's with a language I know. I could send you the AHK source if you wanna try...

[highend]

I could decompile it myself but sure, send it (via e-mail as an .ahk attachment)

What's the exact call from XY's main (for a single file or folder, a selection of files/folders (if that's different))?

[admin]

I'll send the documentation along. Much of it is not even used. The currently used syntax is very simple: I just call "XY64ctxmenu.exe" with a single parameter which is the quoted full path to a temporary text file (in <xydata>\Temp, e.g. XY64ctxmenu.exe "E:\XY\XYplorer.dev\code\appdata\Temp\~XY517C.tmp") that contains all selected items, again full path and one per line, that the menu should be shown for. The only other call is to shut it down on app exit: XY64ctxmenu.exe -quit

[admin]

2. I have read the branches about the x64 version of the XY and on the whole I tend to agree that there is no special need to rewrite it.
BUT there is a huge fundamental omission in XY with starting executables, scripts etc because it starts the process directly without changing the environment for the child.
The environment variables are all WRONG for a 64-bit process (inherit from the current x32 process).
By default, a child process inherits a copy of the environment block of the parent process so we must rewrite them (tricky way) or just "proxify" to XY64ctxmenu.exe (exactly what happens when you start it with the context menu).

File --> DoubleClick --> CreateProcess = BAD
File --> RMB+Open   --> XY64ctxmenu.exe --> CreateProcess = GOOD

I don't see cases where we would want to run with a x32 environment on a x64 machine so it's strange to see that there is no "permanent redirection" (this would have closed all the cases with the advantage of the x64 version).
Of course, launching every executables and scripts via the context menu is a crutch and nobody cannot constantly keep in mind that some files cannot be launched in the usual way (or it may lead to unpredictable consequences).

Thx.

Almost forgot that I have implemented this already within scripting: open64; will open the currently focused and selected file in a 64-bit process. Here's the original change log:

Code: Select all

v21.10.0025 - 2020-09-29 16:06
    + Added SC open64 for debugging. Opens a file from XY64.exe, i.e. from a 
      64-bit process.
      Examples:
        open64; // Opens the selected file
        open64 "C:\Users\Donald\Desktop\Desk\Diana Rigg.jpg";

I could easily add an option to open ALL items that way.

[Antieve]

I have implemented this already

a temporary text file

It seems that half of the time is spent writing to the file and the other half is reading (+ parsing with regular expressions) in ahk.



Highlights

1. Never use temporary files IO operations is a major time waster
2. Avoid creating processes. Start XY64ctxmenu with XY and wait for messages inside.
3. Send message from XY on RMB click. Profit.
4. Avoid any string operations in XY64ctxmenu
   The message should arrive already in the required format and be transparently proxied to the handler (when we want run x64 processes).
   As for menu, we need to minimize the use of regular expressions.
5. Avoid unnecessary checks
   Instead of checking the process\mutex\etc before each message is sent, it is better to start a timer (250-300ms) and if there is no "answer", then do a check and start the process again if it was killed for any reason.
   Deceleration in this case should not exceed the time menu opens now
   Respectively XY64ctxmenu after! opening the menu should send a "success response message"
6. One of the many ways to fix busy cursor on RMB and LMB clicks

PS
And since you will change the algorithm anyway, it makes sense to write an optimized version already for it and not kick the corpse

[WirlyWirly]

I have a couple questions about XYCopy...

1) How do I bring back an XYCopy window after closing it? If I X out of the XYCopy window while also exiting XY itself, XYCopy continues in the background. The only way I can stop the process is by killing it using Task Manager.

2) When copying/moving, does hitting 'Cancel' undo all the changes or stop at whatever point it's gotten to? I've had a couple instances where I accidentally move some critical files out of where they need to be and immediately hit cancel. I'm not sure what the behavior is.

[admin]

I have implemented this already

So, does open64; work for you? Does it make a difference?