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: 54245
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 wrote: 13 May 2022 09:25
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 ;)
:biggrin:

I added FindExInfoBasic on 20150101, but did not find the measurable speed difference so impressive. So I only implemented it half-heartedly. :)

I'll add it to normal browsing in the next beta. Curious about the feedback...

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

Re: A few clarifications on the new version

Post by Antieve »

did not find the measurable speed difference so impressive
Perhaps there is a bottleneck in related procedures. If you add performance counters to the debug code directly to the FindFirstFileExW call, you will immediately see the percentage of speed gain compared to the default method.
I mentioned string optimization earlier for a reason. As an obvious example, - many high-level APIs call strlen inside which is terribly slow by default on Windows (and even slower on x32), just replacing this function with a sse2 masks algo analogue will significantly increase the overall speed of work, etc etc

admin
Site Admin
Posts: 54245
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 wrote: 13 May 2022 07:11 I took the time to watch the beta for more details and here are some quick notes.
...
Thanks for the notes! Will become handy.
Antieve wrote: 13 May 2022 07:11 ... it is very easy to get this handle directly from the child process...
How?

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

Re: A few clarifications on the new version

Post by Antieve »

admin wrote: 13 May 2022 12:31How?
Well, just a couple of options:
  • Super obvious: CreateProcess() ArgX = XYPlorer_hwnd then just send back XYCtx hwnd in message :)
  • Get PID\TID from info returned by CreateProcess then wait for message loop to start (WaitForInputIdle) then enumerate windows (for now tere is two of them, one is clearly redundant) and get hwnd
  • CreateToolhelp32Snapshot > Process32First < [compare th32ParentProcessID with own PID] > Process32Next = PID of XYCtx
    then just GetWindowThreadProcessId\EnumWindows
  • Broadcast message with hwnd and on receive check if child process (in case of several instances of XY)
  • some more exotic variants

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

Re: A few clarifications on the new version

Post by admin »

Thanks! Got it using EnumWindows.

So now I will remove all that temp file business.

@highend: My baby AHK skills are enough now to change the AHK script accordingly. :)

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

Re: A few clarifications on the new version

Post by Antieve »

admin wrote: 13 May 2022 14:59using EnumWindows
Image
Yes! We don't look for easy ways, hard work is the key to success! :biggrin:

But seriously, note for Windows 8 and later, EnumWindows enumerates only top-level windows of desktop apps, and in perfect world XYCtx must use minimal message-only window. The hard way to get it is specify HWND_MESSAGE in the hwndParent parameter of the FindWindowEx function (or NULL in hwndParent and hwndChildAfter to get all), and easy ways for wimps!
Although I love to pick on sub-optimal solutions... damn perfectionism in my head :ninja:
At least hopefully the current code takes into account the probability of multiple identical windows from N copies of XYPlorer.
So now I will remove all that temp file business
:tup:
AHK skills are enough now
It's never too late to learn something new, it's endless and fun!

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

Re: A few clarifications on the new version

Post by admin »

That was a hot tip. I found that FindWindowExW() will return the window handle when I call it with lpszWindow = [full path to XY64ctxmenu.exe] and all other params 0! (Win8.1) Much easier than EnumWindows.

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

Re: A few clarifications on the new version

Post by Antieve »

This is work because the full path is the window caption in fact :)
Although I hinted at the super obvious option because all of its components are already fully implemented, but in general, this is ok also.

I just found a very useful script command get("bitness") and wanted to ask if there is a way to add this information (bitness) to the tooltip of the corresponding files?

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

Re: A few clarifications on the new version

Post by admin »

Bitness: it will just work in the next beta. :)

Filehero
Posts: 2507
Joined: 27 Feb 2012 18:50
Location: Windows 10 Pro x64

Re: A few clarifications on the new version

Post by Filehero »

Joint effort - cool thread. :tup:

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

Re: A few clarifications on the new version

Post by admin »

Code: Select all

v23.00.0309 - 2022-05-13 15:37
    % Browsing and many other things should be slightly faster due to the implementation 
      of a small labor-saving flag in one of the most frequented places in the code.
Does anyone find the app snappier now? I think so, especially when opening larger folders.

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

Re: A few clarifications on the new version

Post by Antieve »

admin wrote: 13 May 2022 19:25Bitness: it will just work in the next beta. :)
:tup: :tup: :tup:

I love this beta. Haven't taken a closer look yet, but the UX is much better now.

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

Re: A few clarifications on the new version

Post by Norn »

admin wrote: 14 May 2022 08:17

Code: Select all

v23.00.0309 - 2022-05-13 15:37
    % Browsing and many other things should be slightly faster due to the implementation 
      of a small labor-saving flag in one of the most frequented places in the code.
Does anyone find the app snappier now? I think so, especially when opening larger folders.
Nice to see the speed improvement, I think the most intuitive thing for users is the speed of switching tabs. :cup:

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

Re: A few clarifications on the new version

Post by Antieve »

Antieve wrote: 13 May 2022 07:11 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)
  4. Very slow menu when selecting a lot of files
CRITICAL #1 and #2 not fixed (But let's leave these boring things for later, I think the reasons and the solutions are obvious)

Let's talk more about multiselection
For a clear demonstration, save the code as test.cmd (or whatever you like) and run it from anywhere. It will create a TEST folder next to itself with lots of files inside and will open it in an windows explorer.

Code: Select all

::&cls&::
@echo off
cd /d "%~dp0"
set TestDir=%~dp0TEST
md "%TestDir%"
echo "Just a moment..."
for /L %%N in (1,1,40000) do REM. >"%TestDir%\%%N.txt"
explorer "%TestDir%"
Now CTRL+A to select all files and RMB to show context menu. Now we have an idea of how it should work.
Time to open this folder in XY then CTRL+A, RMB... You can go and make yourself a cup of coffee :cup:

Don't feel bad about it, because most of the existing file managers get hung up in a similar situation, but we can easily beat them and make XYPlorer (along with windows explorer) work fast! :)

One of the reasons is that you don't follow guidelines
Yes, windows explorer works fast because of passing just first 16 selecting items to a verb. Tricks are everywhere ;)

As far as data transmission is concerned, we can of course use DDE\DDEML (The current implementation is a simplified version of this approach) But (as usual) I can suggest using another trick.

At the moment the weak point is the list of files that we have to generate, send, then read and convert. But (as I said before) this is an extremely inefficient approach.
Why not make the system do everything for us and do it faster than we do?
We can programmatically emulate drag & drop operations on selected files from our window to XYCtx window in CFSTR_SHELLIDLIST format.

In doing so, the OS will create a PIDLs data package for us and all the associated handy WinAPIs will be available in both processes to manipulate it as we want with minimal writing of our own code.
So if we follow the guidelines, the menu will be even faster and won't get hung up on a huge number of files.
Boom! XY#1 FM now also in this :)

PS
And thanks again for the bitness, I really missed this kind of convenient implementation of this functionality
:tup:

admin
Site Admin
Posts: 54245
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 wrote: 14 May 2022 18:35 One of the reasons is that you don't follow guidelines
Yes, windows explorer works fast because of passing just first 16 selecting items to a verb. Tricks are everywhere ;)
Sounds fascinating, but then the shell extensions in the ctx menu (e.g. WinRAR's "Add to archive...") will only work on those 16 items.

Post Reply