Expand by...; attribs (%childcount%, please?) by clipboard, and then more "direct"?

[kinook]

Just to be clear, is the primary feature you are requesting a command, in the tree, for the selected item(s), to expand to different levels (i.e., 2, 3, 4), like you currently can for Tree | Expand All?

[Spliff]

1) %CHILDCOUNT% in UR-commandline would have been necessary for scriptlet above; I helped myself out with the scriptlet below instead

2) It would be more than helpful if we could get immediate access to such system vars (explanation above)

3) It's the "Down-2-levels" below that is really and extremely helpful, any deeper shoveling is much less helpful and can be considered "exotic"; it's obvious though that if you could integrate the "Down-2-levels" below, it would have immediate effect then, instead of taking many seconds in case.


(EDIT: On second thought: IF I also had the Down-3-levels version (which as said, is not possible currently, since I'd need immediate (!) %INDENT_LEVEL% info for every item on second run, I'd very probably use it at least for SOME stuff, so Down-2 and Down-3 would be welcome. ALSO, Down-1 is NOT devoid of sense, since it would imply 1) Collapsing the sub tree (Tree-CollapseAll), and then 2) {right} for just (!) displaying Level-1, in other words, the user can currently do a macro, with the 2 steps one after the other to get there, but just one, internal shortkey (as also for Down-2 and then Down-3) would obviously be helpful, since again, it would avoid the WAIT in-between that external commands, put together, ask for.

The INTEREST of these lies in the possibility to trigger them very high within the db tree, since on the higher-up levels, you can then organize your data in some standardized, "normalized" way: Down-1=core-info/Todo, Down-2=more core info you also want to see at a glance, then perhaps Down-3 for core(-only-) details, and levels -4 and further down would contain further details then; or then, in most use cases: Down-1=core-info/Todo, Down-2="Core-Details", and then on level -3 and further down, the details: This shows that Down-2 to be automated, is really important, whilst Down-3 to be automated will be helpful often (but in a minority of use cases), and the automation of Down-4 though will be more or less devoid of sense, in most situations (while possibly useful in some, rare, special ones.

Hence: Down-1/2/3 should indeed be implemented, Down-1 as a convenience, Down-2 as some sort of "standard tool", and Down-3 for lesser needed situations.)


That being said, the scriptlet below works fine and is worth the wait, but I suppose many users would need to try it out beforehand, then re-arrange some of their things... and then only they will use it though in 80 or 85 p.c. of their use cases in which they currently use Tree-Collapse/ExpandAll (which means the subtree in question).


ExpandBy2Levels()
; to be triggered when respective sub-tree parent-item is selected
{ ; BOF
clipboard =
s =
sendevent, +{left} ; collapse subtree
sleep, 300 ; ms (might not be sufficient for large, expanded sub-trees?)
sendevent, {right} ; expand item
sleep, 300 ; ms (as before?)
sendevent, {down} ; go first sib (all collapsed now)
sleep, 100

sendevent, ^a ; select all sibs
sleep, 200
wingettext, s, A
pos := regexmatch(s, "`amU)(^[0-9]+)(?= items selected$)", s)

sendevent, !{end} ; go last sib (also de-selects them)
sleep, 100
loop, %s%
{
sleep, 100
sendevent, {right} ; expands if children, else does nothing
sleep, 100
sendevent, {up} ; go previous sib (step from last to first)
sleep, 100
}
} ; EOF

Copyright as before.

[kinook]

The latest version (v6.2.0.9) implements commands to show 1 to 5 tree levels (Tree | Show | 1-5 Levels).

[Spliff]

Thank you immensely, Kyle, simply FANTASTIC, makes UR incomparable!

Also for your way of implementing it, the "expand all" now just being the logical "most"/"largest" one of several "expand" commands.

Absolutely PERFECT!