Tested again especially with regard to the “delay at collapse”, option 2 and 3
- Option 2 (keep childs, not clear them at expand)
Didn't encounter any(more) delay at collapse. Having tried various scenarios and different action sequences.
- Option 3 (clear collapsing nodes):
Yes,.the discrepancy between felt time for expand (short !) vs. collapse (long !) appears strange.
This differs surprisingly from the measured real times. Eg: for expand: 0,106s, for collapse 0,049s, which is faster.
This small number measured within "TForm1.ShellTreeView1Collapsed" would look like as if the processing itself is fast, but its gui display simply is deferred by some reasons!
On the other hand, this procedure (ShellTreeView1Collapsed) is really reached very late (seen by setting a breakpoint herein).
If we look in ShellCtrls TCustomShellTreeView.Collapse, apparently there's a lot of time spent for Node.DeleteChildren.
Which appears to me to take much longer as when being called from within option 1. May this be? Mysterious so far.
A next step could be to measure the runtime Node.DeleteChildren takes when being called from within option 1 vs. when from option 3. Do the numbers match? And do they match somehow the 0,049s as reported from the main form?
-------------
In option 1, the expanded subtree is deleted before it is expanded again - therefore expansion is slow from the second time on
Absolutely. Same opimion. Option 1; in a first expand, there's nothing to delete. In subsequent expands, there might be masses to delete. So they are longer by principle. This explains the question asked in the title of this topic.