Synchronize Treeview Issues in v1.4 beta & dev

Found a bug or something that needs fixing?
Post Reply
crispyoutside
Posts: 4
Joined: Fri Jun 26, 2020 6:35 am

Synchronize Treeview Issues in v1.4 beta & dev

Post by crispyoutside »

I have been experimenting with the beta code and have found an issue. If I open multiple tabs and have "Synchronize Treeview" enabled only the first (left most) tab synchronizes.

I'm running Win10 Pro - 2004 build 19041.329 x64.
I've reproduced the problem using both 32 and 64 bit versions of Explorer++ and two separate builds 1.4.0.1637 beta and 1.4.0.1657 dev

If I reinstall the current release 1.3.5, it works as expected (synchronizing each tab as selected).

Thanks for your hard work.

Neil
crispyoutside
Posts: 4
Joined: Fri Jun 26, 2020 6:35 am

Re: Synchronize Treeview Issues in v1.4 beta & dev

Post by crispyoutside »

Additional note: I am reproducing the issue linked below when I revert to v 1.3.5 (and I obtain the issue on mapped drives, not just UNC paths).

viewtopic.php?f=5&t=1943&p=5055&hilit=s ... view#p5055
Last edited by crispyoutside on Fri Jun 26, 2020 6:55 am, edited 1 time in total.
crispyoutside
Posts: 4
Joined: Fri Jun 26, 2020 6:35 am

Re: Synchronize Treeview Issues in v1.4 beta & dev

Post by crispyoutside »

So I've examined the code base enough to see that this is not a bug, but rather the "Synchronize Treeview" function is explicitly disabled for UNC and mapped paths. In connection with this disabling, the TreeViewHandler.cpp function Explorerplusplus::UpdateTreeViewSelection() contains the following note:
/* To improve performance, do not automatically sync the
treeview with network or UNC paths. */
So I have two new questions:
1) Is this a continuing issue or is it historical (and no one has revisited it recently to see if it still matters)?
2) If I were to revisit it, is there additional information somewhere to offer me some perspective on the nature of the issue (beyond the nebulous "performance" rationale)?
JMHaro
Posts: 3
Joined: Wed Jul 29, 2020 11:21 pm

Re: Synchronize Treeview Issues in v1.4 beta & dev

Post by JMHaro »

I know this discussion was a little old, but this has really been bugging me a lot. This is the only main issue I'm having with Explorer++ is the none syncing (just about all my work is done on mapped drives). Does anyone know if this is just the beta version issue? I haven't tried going back to the actual release version yet.
David Erceg
Site Admin
Posts: 933
Joined: Sat Apr 18, 2009 1:46 am

Re: Synchronize Treeview Issues in v1.4 beta & dev

Post by David Erceg »

Regarding performance, the issue is that to show a folder within the treeview, you have to enumerate each of its parent folders, something that can take a significant amount of time. For example, simply enumerating the Network folder on my PC takes about 30 seconds, even though there are no other PCs on the network.

That means that to select a UNC folder that's ultimately contained within the Network folder, you would have to wait for the Network folder to be enumerated, which might not be a quick process. Since all that work is done on the main thread, the entire application will hang during that time, which is particularly noticeable on startup.

Mapped drives might be a different story, since they would be contained within This PC instead.
Janus
Posts: 46
Joined: Fri Aug 05, 2016 9:03 am

Re: Synchronize Treeview Issues in v1.4 beta & dev

Post by Janus »

@David Erceg

Are you serious about enumeration time for treesync?
30 Seconds?
How does it take that long for you?
What speed is your network?

Even before I integrated voidtools everything into my personal branch for folder sizes, treesync never lagged more than a second or two.
And that was with two windows servers( XP & W7), a linux server, and a linux based media player on the network.
Browsing any of them, including the media player that had a drive in it.
That was also before I converted from 10/100 to GB.

I have never seen a 30 second delay on tyreesync.
One sort of exception, a customer had mapped a drive letter to an online ftp site, don't bother asking how, I didn't want to know, that took a while to enumerate sometimes, but they were also one of a couple of dozen sites mapped in, some delays were significant since they had DSL.

In my version I do the following.
Keep the treesync even on unc paths.
Disable click in blank area up directory, I $&@@%& that one.
Kill natural sorting, so numbers in names are ignored, again, I really &*%$* that "feature".
KILL!!!! hot tracking, there aren't enough letters in UTF to make enough words for how I feel about that one.
Those are all personal preferences though, and to each as they prefer.

Add Everything to folder size computation so it uses that instead of walking the dir tree if folder size is on and everything has it indexed.
It also falls back if everything is not loaded.
Also, you you can add network folders to "everything" to make searches fast.
I can put up a diff against commit 2050 if you like, so you can see for yourself.

@JMHaro
Here are completely static linked compiles in x86 & x64 derived from commit 2050.

http://www.simulatorlabbs.com/void/Expl ... _210101.7z

CRC 683EC78E & 386FDB1D according to 7-zip 19.00(x64)
I also run them as administrator for stability and dependability, I got tired of UAC and permissions popups.

These are what I use everyday, straight from my quicklaunch folder.
My desktop is W7 Pro x64 with openshell in full classic mode, 7+ taskbar tweaker, network activity indicator & voidtools everything.
Search service, homegroup, zip folders & superfetch all disabled.
All of it made as 2K/XP like as I can make it.

I intend to drop windows when ReactOS goes beta, so looking forward to that.
Hoping to not be forced onto W8.1 in the meantime, but W10 is not an option, I have to keep my stuff secure.


Janus.
Post Reply