Explorer++ folder size column fix using Everything, if anyone wants it.

[Janus]

I have just gotten working replacing the foldersize function in explorer++ with an Everything search instead.
Now instead of reading and calculating folder sizes via disk or lan, it just asks Everything, for everything.

It is currently Alpha, but works so far.
It also gives the sizes of shares on lan servers that are indexed just as fast as it does on disk.

If anyone is interested, let me know.

I warn you though, I am not a real C/C++ programmer.
The code will need reformatting and cleaning for more general usage.


Janus.

[therube]

So this is integrated into Explorer++ or only called from Explorer++?

How about a screenshot.


(Can't believe that he includes the word " bytes" in the size column [when set to bytes]. You should request that the word 'bytes' be dropped.)

[Janus]

@therube

I replaced the procedure

HRESULT CalculateFolderSize(TCHAR *szPath, int *nFolders, int *nFiles,PULARGE_INTEGER lTotalFolderSize)

In the file FolderSize.cpp under Helper.

The program looks exactly the same, only it fills in the size data for folders from Everything instead of spending time reading the drive directly.

Right now it replaces the normal routine, returning zero (0) if the directory is not indexed, or Everything is not loaded.
I will will be adding a fall through back to the old routine when I get time.

And it is a lot faster than letting explorer++ try to read Seamonkey, Reactos' SVN tree, Or Android's, or ... Well, you get the idea.

P.S. I replaced bytes with a capital B in mine.

[Janus]

Update:

I have finally removed the need for external support DLLs to get Everything functionality in explorer++.
All of the functions needed for folder size are now a part of the main program.
It checks to see if Everything has a directory indexed, via direct IPC, then gets it data that way, or falls back to the old code if not.
{IPC == Interprocess Communication. This is the same thing the DLLs and the gui do.}

As long as the directory is in the index, I get about a second's delay filling in values with hundreds of directories.
I am still testing to verify, but it isn't going to take long.

Would anyone be interested in testing explorer++ with everything integrated for folder sizes?

I can provide binaries in x86, or x64, and I am going to be posting the full source once I have cleaned up the integration.


Janus.

[horst.epp]

I use Everything integration in Total Commander and also have many other file managers (Free Commander, Unreal Commander).
Explorer++ is much to limited and easy to crash so I don't see any benfit in such effort.

[NotNull]

Don't be grumpy, @horst.epp
I can see why he did this: if you want (instant) folder sizes in your file-manager, you could write your own from scratch òr start with the only one (that I know of) that has it's code open sourced.

BTW: I 'always' have a copy of Explorer++ around
- highly portable (1 exe + 1 config file); < 2MB
- handy for an elevated file-manager (you can't with Explorer)
- because of the way it is written (different API's) able to bypass some Windows security restrictions (that's all I will say about that).

But you are right: there are probaqbly better options for your main file-manager.

And yes, I am interested in testing the x64 version. Will contact you in about 2 weeks (no large time-blocks till then)

[Janus]

@NotNull

No problem on the time.
As I said, I am still testing.

When I am happy with it, I will be putting up exes and the source.
Source is setup for VS2015, with all third party libraries in the source tree.
Everything is fully static linked, no external or support files required.
The same basic setup I use for celestia.

I should also warn you there are things I have removed as well.

As a side note, for me there is no better file manager for what it does.
None of the others have the directory tree pane, which I use to navigate.
The only other one I use is ztree, which does things completely differently, for different purposes.


Janus.

EDIT:Spilling fix.

[NotNull]

I should also want you there are things I have removed as well.

I hope you want to WARN me?

None of the others have the directory tree pane, which I use to navigate.

That is not entirely accurate. Most of these dual-pane filemanagers do have a treeview, but not enabled by default.
(I use a quad-pane file-manager with - if needed - 4 separate trees, although I only use 2 panes and no treeview. Each his/her own personal preference)

[Janus]

@NotNull
Warn is the proper word, and I have flixed my spilling horror.

As for what I removed.
Sound, I dislike a large amount having a any clicking from my computer besides my keyboard and my mouse.
Double click not one something in a pane to navigate up, gone.
Double click on tab to close, gone.
'Bytes' changed to 'B' in size.
A few defaults.

Little things, but they all interfere.
Since I will be posting the code, anyone who wants can use as much or as little of what I do as they like.


Janus.

[NotNull]

Thanks for the heads up.
Now I will have to learn myself some C++ to re-enable the double-click in empty space to go up (brilliant feature; use this in my current filemanager very often)

BTW: no need to remove the "Double click on tab to close". Just disable this feature in the options dialog.

BTW2: Are all sizes in bytes or dynamic (li,e the rest of Explorer++ (KB/MB/GB)

[Janus]

@NotNull

The doubleclick on tab to close is removed so when I use it on a fresh system it doesn't annoy me.
I simply compile it to have my preferences by default, then I have a nice portable tool that is preconfigured.
I did the same with notepad++ which I have configured to always convert to ascii on load.
One my largest uses for it is stripping out utf & unicode, both of which are a mess for me.

I also removed the pretend to sort like a human code, instead using strcmpw which is more logical for me..

Large sections of my work is troubleshooting or prototyping.
There is no larger nearly invisible mess than an object or class twenty layers in that tests letters directly.
Checking a byte for 0x20/$20/32/o40 instead of a string for a space is common, as 0x41/$41/65/o101 and so on.
This is especially common in small assembly routines that sit under large libraries.

Then again, I have many times tracked down a function deep in a library in order to remove pointless overhead.
Duplicate the single or few functions, then lose the library.
Sometimes the overhead is actually needed though, but a majority of the time all it does is eat memory and speed.

As for the navigate up, try listviewhandler.cpp:150

Code: Select all

				/* NM_DBLCLK for the listview is sent both on double clicks
				(by default), as well as in the situation when LVS_EX_ONECLICKACTIVATE
				is active (in which case it is sent on a single mouse click).
				Therefore, because we only want to navigate up one folder on
				a DOUBLE click, we'll handle the event here. */

				//if(ht.flags == LVHT_NOWHERE)
				//{
				//	/* The user has double clicked in the whitespace
				//	area for this tab, so go up one folder... */
				//	OnNavigateUp();
				//	return 0;
				//}

I have mine defaulting to B for bytes, but the other options KB/MB/GB are still present.

Right now I am fighting a network share updating problem.
Not sure yet if it from the XP on machine with the share, openshell, 7+ taskbar tweaker, or with explorer++.
The regular explorer sometimes glitches, but its windows, it always has, but it mainly works for catching updates, it is simply unusable for anything other than testing..
Still wading through wireshark logs to make sure the samba/cifs onchange messages are there to be found.


Janus.