XYplorer Beta Club

Posted: **13 May 2022 10:29**

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

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...

Posted: **13 May 2022 10:45**

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

Posted: **13 May 2022 12:31**

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?

Posted: **13 May 2022 13:42**

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

Posted: **13 May 2022 14:59**

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.

Posted: **13 May 2022 16:09**

admin wrote: ↑13 May 2022 14:59using EnumWindows

Yes! We don't look for easy ways, hard work is the key to success!

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

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

AHK skills are enough now

It's never too late to learn something new, it's endless and fun!

Posted: **13 May 2022 18:15**

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.

Posted: **13 May 2022 18:48**

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?

Posted: **13 May 2022 19:25**

Bitness: it will just work in the next beta.

Posted: **13 May 2022 23:34**

Joint effort - cool thread.

Posted: **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.

Posted: **14 May 2022 11:45**

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

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

Posted: **14 May 2022 12:40**

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.

Posted: **14 May 2022 18:35**

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:
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)

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

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

Posted: **15 May 2022 10:24**

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.

XYplorer Beta Club

A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version

Re: A few clarifications on the new version