XYplorer Beta Club

This is a continuation from here: viewtopic.php?p=192570#p192570
Bug is still here with 22.40.0211 as shown in the gif.
It only happens with FVS on, obviously. Like I said, I am using a default FVS. Not sure if it also acts like that with a folder based FVS.
And it seems to not happen that often when the folder sizes are low or few.

Cannot reproduce. Could it be related to "Session Manager"?

Have you tried disabling your CEA browse/paint scripts, possibly they could be creating a race condition, since you say it is intermittent.

jupe wrote: ↑07 Nov 2021 10:46 Have you tried disabling your CEA browse/paint scripts, possibly they could be creating a race condition, since you say it is intermittent.

Ok, I finally pinned it down to the following for reproduction:

1. fresh;
2. Move one tab over to the right (to the Documents tab, or any other tab with subfolders with data in it).
3. Define this folder view as default.
4. Add the line loadtree tab("get", "data"), 0; to the CEA "After browsing a folder".
5. Turn on #417 (Show Folder Sizes).
6. Switch to a differnt tab (e.g. the user folder - third tab in a fresh instance).
7. Switch back to the tab with subfolders with data in it. -> The toolbar button #417 should get disabled but the folder sizes are still being calculated. (If one works with cached folder sizes, the problem might be harder to see, but it is still there.)
8. Switch back and forth again. -> Folder sizes are not displayed anymore.

Turn off FVS and all ok. Deactivate the CEA and all ok.
Weird thing, the default FV seems to be applied to the 2nd tab ok, but switching back to the first tab it causes a glitch in connection with loadtree in the CEA. And it does not matter, which tab (or folder) the first tab was.

Thanks, could reproduce it now.

Generally, injecting scripts into the normal flow via CEA is a risky business. Some procedures in XY are timer-triggered to enhance the smoothness of the experience. Now injecting a script here can results into a race of timer-triggered tasks. The result may be predictable or not, and sometimes it may not be desirable.

To work around your particular issue I added a flag to SC loadtree which you should use in your CEA script: loadtree tab("get", "data"), 0, 1;

Change log (v22.40.0213):

cool, thank you.

22.40.0213
Nice flag for loadtree, however now...

1. fresh;
2. Add the line loadtree get("tree") . "|" . listfolder(tab("get", "path"), , 2 + 64), 0, 1; to the CEA "After browsing a folder".
3. Navigate around a bit in the tree in deeper nested folders (up and down the tree; different nesting levels; different branches) -> Sometimes the folder in the tree highlighted as "currently active" is not the same as navigated to and shown in the list. Unfortunately no pattern detected. The more one navigates around the messier it seems to get.

Hm. Guess you hit the limits of CEA there. Maybe another event is more suitable, e.g. after painting?

admin wrote: ↑07 Nov 2021 19:14 Hm. Guess you hit the limits of CEA there. Maybe another event is more suitable, e.g. after painting?

This really happens with all 3 location change CEAs.

Maybe I could fix it. Tomorrow...

Seems to be solved now. Thank you!

Just reusing suitable topic title.
Not really a bug, but FYI I noticed that since icons were added to manage FVS, when a VF is set within, the icon shown is the dual loc icon, unsure if you wanted it like that. (also what is the :id for dual?)

Dual has no :id, it is marked by the presence of ||. So, damn, we have a collision here. Need to apply some extra smarts.

I think I worded that badly, I meant the icon :id, not cmd. As to the manage FVS changes in .0108, what do you think about having the VF overlay (like used on tabs/catalog) instead, or would that be difficult/unnecessary, anyway it's just a suggestion.

Button? What button?

Oh, you mean the icon: :dloc