XYplorer Beta Club

Finally! :-)
That makes sense... so I can use the default columns for Downloads and extended columns for the many folders where it helps to know when files have been sync'd or the length of videos.

Yep.

Alright, hearing that slow columns can be problematic made it easier to capture the bug.
I made a test folder with some files and started a batch script that renames "test.txt" to "test.bat" and back. The recorded GIFs are best viewed with a video player like MPC-HC, frame by frame with Ctrl+Right/Left (VLC does not play the GIF).

In the first GIF, I have the slow column Custom size circles visible, and renaming happens every 5 seconds.
I mark "test_158.txt" and keep Ctrl pressed. Just when the batch renaming triggers a list refresh, I right-click "test_152.txt". File "test_152.txt", under the cursor, gets replaced by "test_009.zip", and the context menu shows up afterwards. Still keeping Ctrl pressed, I left-click "test_024.zip". In that moment, "test_024.zip" turns into "test_010.zip". Once the re-sorting is finished, I am unaware that "test_010.zip" got selected because that file is off screen. I release the Ctrl key and right-click "test_152.txt", but nothing happens because of another list refresh. The second right-click and delete on "test_152.txt" reveals that not one but two files were selected.

In the second GIF, I removed the slow column and renaming happens every second. The file sorting bug is not present, but XYplorer doesn't register mouse clicks when a list refresh is happening. I this a separate second bug?

It can be argued that slow columns come with a drawback. But the list was sorted by Modified, not by the slow Circle size. Does XYplorer not sort by Modified first, and then calculate and draw the size circles?
I noticed that the two wrongly placed files "test_009.zip" and "test_010.zip" were at positions 5 and 6 in the list. These are their positions in the list when it is sorted by Name!
Maybe triggering a list refresh sorts it by Name internally first, before the list gets sorted by the selected column and redrawn. When users interact with the list during a refresh, the wrong files can be selected and XYplorer briefly draws the internally sorted file. This does happen sometimes without interactions, where it doesn't cause trouble, but it is visible.

When you open the black boxes and reveal the rename script and the slow column script, I can look it into when I find some time, but generally: Caveat scriptor!

Oh ja, sorry

The batch script was run in a command prompt to simulate changes to the file system by an external program:
The Custom size circles were introduced in v17.80.0001 and I use a slightly modified version of the original script:
I know that I can use the fast macro instead. But the custom circle sizes and colours with a script are important to me because they allow for a visually more intuitive size representation. Especially the colour change from dark blue to light blue to orange to red makes identifying file sizes much quicker.

Anyways, this isn't about my stubbornness to use a script instead of a macro. I don't think re-drawing a custom column slowly due to a script would be problematic in any way. The problem is that the other (fast) columns not only are affected by the slow column, but that the effect is causing a glitch that can lead to the selection of random files by accident and without the user's knowledge. The user sees a list sorted e.g. by date, but internally it is sorted by name with files/folders at vastly different positions from what can be seen on the screen. Essentially, with a slow column active, users mustn't select anything when e.g. a browser downloads a file into the same folder.

Thanks! Could you also send your XYplorer.ini to support. I have to reproduce the auto-refresh settings exactly.

There is no need to test my configuration as the behaviour is the same in a fresh installation. Of course you have to add the Custom size circles column first. I was able to observe both, the inconsistency between what the user sees and how files are actually ordered internally during a list refresh with a slow column, and mouse clicks not being registered (anywhere on the XYplorer UI?!) during a list refresh even when no slow column is present.

Yep, I can see it now. The only solution is a radical block: no clicks or keys while the list isn't completely loaded and sorted. Next beta (32/64).

Oh, a radical block sounds radical

Any chance of getting some crazy multithreaded asynchronous magic sometime in the future? (far future, no pressure)
Or maybe an XYpu accelerator PCIe card?
But seriously, I think it would be acceptable for slow columns to update at a slower speed than the fast standard columns. They could be greyed out until they are done refreshing. Input for these greyed out columns must be blocked, but users can interact with the fast columns that finished refreshing already. If a slow column was selected for sorting, all columns would have to be greyed out and blocked until that slow column is done.
Here is another idea: Have an animated waiting/loading circle in the slow column while it is greyed out to indicate why it is inaccessible or frozen right now. (These are really just ideas to spark interest and not requests)

For now, will you turn the mouse cursor into a waiting/loading circle to show users that inputs are blocked?

Crazy multithreaded asynchronous magic is planned for the future. For now I'll stick with the paleolithic block method.

Thanks for tracing the original problem which took more skill than I have!
I like the idea of leaving slow columns to be displayed after a faster sort on the other columns (unless a sort on a slow column was requested).
But blocking selection during sorting sounds a reasonable next step.