Explorer++

I can't reproduce this; opening Explorer++ 1.3.5 on Windows 7 Pro SP1 works fine for me. Does the same thing happen when you use the latest dev build (you can obtain that from https://ci.appveyor.com/project/derceg/ ... /artifacts)?

In terms of the next release, the current beta is likely what will become 1.4 (without any other changes). I just haven't gotten around to making the release yet. There are bugs in the beta that have since been fixed and there are other issues I know about, but it's probably not worth holding the re...

No, it's not abandoned. The most recent beta was released several months ago and the last commit was earlier this month.

There's no need to actually implement anything or make changes to Explorer++ if you want to use the current dark theme implementation. That implementation is available in the development builds and you can download the most recent build at: https://ci.appveyor.com/api/projects/derceg/explorerplusplu...

I agree that those sorts of additions would be good. The trouble has always been that Win32 controls are difficult to style and customize. Which means that these sorts of changes might be technically possible but difficult to implement well. If there was an open source library that offered a tab con...

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

For reference, dark mode has been mostly implemented in the development builds for about 6 months now - see https://github.com/derceg/explorerplusplus/issues/115.

Dark mode has been mostly implemented in the development builds for about 6 months now - see https://github.com/derceg/explorerplusplus/issues/115. Since the request for a dark mode has been in this forum for years, with zero action, I would ask that instead of adding a dark mode, just allow the Exp...

Oh, first browsing is faster allright. That's good to know, at least. It's a bit frustrating that the best performance would come from having a split implementation, when a unified implementation is simpler. Personally, I think there would be much greater gains made from performing the enumeration ...

After investigating a bit further, it looks like the reason why IShellFolder2::GetDetailsEx has the same performance as SHGetDataFromIDList is that they both retrieve data cached within the PIDL. The behavior of SHGetDataFromIDList is discussed at https://www.zabkat.com/2xExplorer/shellFAQ/bas_xplor...