A few clarifications on the new version

Please check the FAQ (https://www.xyplorer.com/faq.php) before posting a question...
admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »

WirlyWirly wrote: 11 May 2022 06:18 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.
1) You cannot bring the XYCopy window back. And normally XY should kill all XYCopy processes on Exit. If it doesn't there might have been some race condition.

2) Cancel stops, no undo. To undo use the Undo command. :)

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

admin wrote: 11 May 2022 10:24So, does open64; work for you? Does it make a difference?
Yes it works.
You can easily test it yourself here is a script (just save it as Test.cmd)

Code: Select all

::&cls&::
@echo off
(chcp 65001 | find /i "Active" >nul 2>&1) || (echo  ● Unable to set UTF8 output & pause > nul & exit)
wmic Alias /? >nul 2>&1 || (echo  ● wmic unavaliable & pause > nul & exit)
(wmic os get osArchitecture | find "64" >nul 2>&1) && (if %PROCESSOR_ARCHITECTURE%==x86 (echo ● Unable to continue x32 environment detected & pause > nul & exit))
echo  ● We good to go! & pause > nul
But the startup delay is clearly noticeable :|
I hope we will fix the XYCtx and everything will work quickly (because now, in addition to the quick menu, he will be able to quickly launch files).

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »

So, I could add an option to always open64 files to Configuration | Other | Shell Integration | 64-bit Windows. Not sure how to call it. Open files in 64-bit environment? Open files from 64-bit process?

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

admin wrote: 11 May 2022 11:19 So, I could add an option to always open64 files to Configuration | Other | Shell Integration | 64-bit Windows. Not sure how to call it. Open files in 64-bit environment? Open files from 64-bit process?
I think the last variant will be more understandable for ordinary users, although programmers will thank you more because for python, java, various debugging tools and even system scripts , this is a pain in the ((


But once again I emphasize that the launch should still be accelerated

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »

Check out v23.00.0308.

Norn
Posts: 416
Joined: 24 Oct 2021 16:10

Re: A few clarifications on the new version

Post by Norn »

Now it's faster and the busy cursor is gone. :tup: :appl:
Dark mode is next...
Win10, Win11 @100% 2560x1440 22H2

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

admin wrote: 12 May 2022 11:32 Check out v23.00.0308.
There is only 23.00.0300 in downloads and I don't feel any difference in work or some new menu items
¯\_(ツ)_/¯

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »


Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

Well, compared to what it was, I think this is a very good result. :tup:
New setting for x64 run is also works.

jupe
Posts: 2757
Joined: 20 Oct 2017 21:14
Location: Win10 22H2 120dpi

Re: A few clarifications on the new version

Post by jupe »

With the recent x64 menu update, I noticed that it seems like it may now be communicating without utilizing temp files, which is great, but it still seems to create 1 temp file on initial launch, is that necessary still?

highend
Posts: 13274
Joined: 06 Feb 2011 00:33

Re: A few clarifications on the new version

Post by highend »

It's using WM_COPYDATA once it was invoked for the first time for that XY instance (one of the reasons I've modified it for Don). The first call is still a command line call and that (still) contains the path(s) in a .tmp file as an argument. xy64ctxmenu returns its own window handle to XY so that WM_COPYDATA can be used for all following calls. Btw. all XY instances now have their own xy64ctxmenu instance and they won't linger around anymore because they autoquit when their belonging XY instance disappears

The strategy could be changed:

1st call without <paths> just to get the handle back when that calling XY instance doesn't have a handle yet when xy64ctxmenu is needed (either through a context menu request or open64 is used
One of my scripts helped you out? Please donate via Paypal

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

I took the time to watch the beta for more details and here are some quick notes.

Something goes wrong with realization because:
  1. XYCtx window spamed with WM_TIMER messages all the time
  2. XYCtx have a memory leak
  3. XY(Ctx?) shows non relevant menu sometimes on multiselect (this is an old bug)
    How to reproduce: Ctrl+A to select all files (in the folder with mixed content) then right click on image file and we have extra menu items (rotate left\right, set as desktop wallp)
  4. Very slow menu when selecting a lot of files (before it was veeery slow now faster but still kind of slow)


Details
  • In the case of selecting a lot of files
    - XY spend a lot of time preparing the message data packet
    - XYCtx spend a lot of time to read and parse it and then convert every item to PIDLs

    As long as our size limit is MAXDWORD (COPYDATASTRUCT\cbData is type of DWORD) and we can send any type of data you can try one trick
    While I was testing the menu interfaces, I noticed that PIDLs on x32 and x64 are formed exactly the same, so you can completely get rid of reading and parsing in XYCtx if you'll send data as your own structure with PIDLs inside instead of text.
    PIDLs is very simple


Example of custom structure:

Code: Select all

Structure {
   WORD XYArgs
   WORD PIDLs_Count
   ;
   WORD ParenDirSZ     ;| similar to _SHITEMID\cb    (PIDL)
   BYTE ParenDirStr[1] ;| similar to _SHITEMID\abID
   ;
   PIDL ;
   PIDL ;  collection of PIDLs
   PIDL ;
   ...
   PIDL ; Last PIDL (PIDLsCount) with cb=0 is the end of data
}
So in XYCtx just
  • pass ParenDirStr to IShellFolder::ParseDisplayName (when getting Parent.IShellFolder)
  • pass PIDLs_Count and pointer to first PIDL to GetUIObjectOf (when getting IContextMenu)
  • Profit!
    (Yes I know that now in XYCtx you use shell32\SHParseDisplayName which uses absolute PIDLs but the method above will be faster and shorter and of course there is no point in enlarging the message with absolute pidls)
The only thing I want to note is that you need to write the code as optimized as possible on the XYPlorer side (this section of code should be profiled and optimized in any case).
Try to use functions based on SSE2 instructions, this can significantly speed up work with strings. They are not inferior (and sometimes even superior) to the AVX variants and are present on almost any processor.

And another trick you may try - no need to get IShellFolder root interface on every message (looks like it's stay the same for one Windows session)

This is all about the current implementation of the algo.
However, there is an option (more difficult to implement) to be able to handle selections from multiple folders and show extended menu not DEFAULTONLY (it's not multiselect in one folder!)
With this you can select random files for example from disk search results and zip them or do something else.

Using a temporary file to pass the window handle... this is of course a crutch, because it is very easy to get this handle directly from the child process, though it's not critical at all.

I think that's enough for today :D

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »

PIDLs...
I get my folder contents with FindFirstFile which returns strings, not PIDLs. Later converting those strings to PIDLs is very slow.
And another trick you may try - no need to get IShellFolder root interface on every message (looks like it's stay the same for one Windows session)
Sounds interesting! I'll try that... :tup:

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

admin wrote: 13 May 2022 08:30I get my folder contents with FindFirstFile which returns strings, not PIDLs. Later converting those strings to PIDLs is very slow.
Yep.
Now it works like this:
  • FindFirstFile\FindNextFile\FindClose to get list of paths
  • Send this list data in message to XYCtx
  • And inside XYCtx you parse data then convert paths to PIDLs and get all interfaces for menu
I just suggested saving time by excluding one costly operation from the chain and moving the second one from XYCtx to XYPlorer (where you can optimize the code in a familiar language), that's all.

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

admin wrote: 13 May 2022 08:30I get my folder contents with FindFirstFile
BTW in FindFirstFileExW use fInfoLevelId = FindExInfoBasic this will speed it up ~25% (does not query the short file name, improving overall enumeration speed).
In file searching procedures you haven't forgotten about it ;)

Post Reply