I took the time to watch the beta for more details and here are some
quick notes.
Something goes wrong with realization because:
- XYCtx window spamed with
WM_TIMER
messages all the time
- XYCtx have a memory leak
- 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)
- 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