No issue, only a little idea for smoother start

[klaus101]

This is no issue, and not severe at all of course. Please take it as a little suggestion. I always have the explorer control opened when starting NPP. I noticed that at program start you can see a "little animation" until the tree node selection finally does reach the targeted directory. All other controls do appear immediately.

From own programs (Delphi) i know that could be avoided by delaying the screen update a bit (suspend intermediate repaints) by simple measures (Items.BeginUpdate/EndUpdate; LockWindowUpdate(treeview.handle), ..) or such. Maybe in CPP there's something similar for child node expanding resp. ScrollIntoView and it could be interesting to try it.

It's only a small idea besides. The prog start (or switching to "folder of current file") might appear smoother by that. Besides it could be useful if one day "Auto-Sync folder view with selected file" (#30) is considered, which is a good suggestion imo.

Btw the plugin is very cool!

[klaus101]

Just for interest, i did a very short look what might be inside BeginUpdate/EndUpdate for speeding tree population. Probably it's SendMessage WM_SETREDRAW applying the belonging parameters, eg. the handle of the treeview and wparam parameter True or False.

Just for interst i now looked into the sources of the explorer tool Explorer++ 's sources. They are using exactly that `

SendMessage(m_hTreeView,WM_SETREDRAW,(WPARAM)FALSE,(LPARAM)NULL);
 // ....
SendMessage(m_hTreeView,WM_SETREDRAW,(WPARAM)TRUE,(LPARAM)NULL)

Other example: https://www.pcreview.co.uk/threads/how-to-disable-treeview-screen-update.3477775/

Wouldn't it be nice to give such a try??

[oviradoi]

Thanks for the suggestion. I will try it out and see if it will improve things when I have some more time to work on the plugin

[oviradoi]

I have tried this and it does not seem to work as expected.

There is no animation on startup, it's just the code that populates the tree and goes to the current folder. Because we have to add the parents to the tree before adding the children, it will take some time to enumerate all the files and folders from the root to the current one. This will take longer if the current folder is deep in the hierarchy, and it will take less time if the folder is close to the root.

Disabling the redraw will not make this process faster. It will take the same amount of time, but the tree will be blank until everything is ready. I think this is worse than just displaying the items bit by bit.

I will leave this issue open and maybe I can try and see if there is some other way to make this process faster.

[oviradoi]

I managed to identify the cause of the slowdown. It was the code that extracts the icons of all the folders and files. I refactored it and I managed to make it a lot faster. So now, the startup time should be better for the latest version of the plugin.

I have released a new version of the plugin with this fix. You can try it out in version 1.9.8.

[klaus101]

Oh, that surprises me a lot, because from own programming experiences (psscal) i know that this stop/populate/start of tree rederaw does make a very big difference when populating a tree resp. iterating to the target node.

Once (12 years ago) i tried an own explorer NPP plugin (Delphi 32bit) - but: no 64bit version for the wrapper, no themes, so i didn't pursue it further -> your plugin is excellent!! enough, so there would be no need. For info i add a short video (showing multiple stop/starts) for to show how that start would/could look like when using such mechanism.

You had no difference, really? (btw, forgot to mention, i simply assumed it's about a standard windows treeview control).

Nevertheless, don't mind. Icon retrieval is a factor, so the 1.9.8 appears to be a bit faster. But you still can follow visually the node iteration down the tree clearly, which is, imo, fully avoidable.

https://user-images.githubusercontent.com/31130146/224485618-c458be21-ccc9-4f6e-a668-0efd3f0fca06.mp4