when re-expanding the node, this is done instantly without clearing/repopulating the nodeWhat if the collapsed node's children are physically deleted from the hard drive while the node is collapsed? Isn't the (re)read on expand intentional? I wouldn't call it redundant. Maybe you can introduce a new flag, when set to true, the disk changes are ignored for an already loaded node.
No more node population is done again redundantly. And certainly not it should take twice the time.
I'd expect that an already populated node can be re-expanded instantly.
A nice side-effect i could imagine is that a re-populated node will on-the-fly catch all modifications of the folder subtree needed from actions outside.
But imo that would be rather a question of how to deal with file change monitors.
I think I'll add an ExpandCollapseMode property:
type TExpandCollapseMode = ( ecmDefault, // Current behaviour (--> default) ecmKeepExpanded, // Do not clear children of already-expanded, but collaped nodes (d7-2-laz's code) ecmCollapseAndClear // Clear children when node is collapsed );
What's strange is that deletion of the child nodes in the C:\Windows\WinSxS subtree takes much longer than adding them...(with option 1, previous behaviour, for to assure)
I think there is some caching on the OS side...QuoteWhat's strange is that deletion of the child nodes in the C:\Windows\WinSxS subtree takes much longer than adding them...(with option 1, previous behaviour, for to assure)
Yes, i saw that yesterday evening too. What i find strange: when retrying it now again, there is no delay at collopse (option 1). Sometimes yes, sometimes no? Hmm
Will try some more retests about that (especially collapse) this evening
In option 1, the expanded subtree is deleted before it is expanded again - therefore expansion is slow from the second time on