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

[Spliff]

Kyle, could you please add some more %attrib-var% for the item-command-line, especially, and urgently, for "childcount" (i.e. some item's number of children)? I would then republish the scriptlet below, but with automated loop iteration number:

F12:: ExpandBy2Levels() ; or whatever shortkey (with () here, too, I had mistakenly left them out on first try)

ExpandBy2Levels() ; to be triggered when respective sub-tree parent-item is selected
{ ; Begin of function
; get n for the current item (would be easy with %childcount%, whilst just taking 1s since involving clipboard)

sendevent, ^1 ; "go tree" (allows triggering even from content-pane)
sleep, 300
sendevent, +{left} ; shift-leftarrow or whatever for 2)-Coll (Tree-CollapseAll)
sleep, 500 ; milliseconds (might not be sufficient for large, expanded sub-trees)
sendevent, {right} ; or whatever for 3)-Exp (regular "expand item")
sleep, 300
sendevent, {down} ; "go first sibling" (all collapsed now)
sleep, 100
sendevent, !{end} ; alt-end or whatever for "go last sibling"
sleep, 100

; currently, some reasonable number of iterations,
; too many will do NO harm, but just make you wait:
loop, 25 ; then: loop, %n%
{
sleep, 100
sendevent, {right} ; expands if children, else does nothing
sleep, 100
sendevent, {up} ; go previous item (we step from last item to first one)
sleep, 100
}
} ; End of function

This scriptlet, applied on the source-item, could also be extremely helpful indeed!


Getting the childcount by commandline>clipboard obviously is very reasonable here, since in the above scriptlet, we retrieve it just once; for other attributes where such retrieval would have to be done for every iteration of a loop, the commandline>clipboard obviously is less helpful, but there are many occasions where e.g. %indentlevel% and other attributes would be of great use, thus my suggestion to make them available that way, too.

It's obvious though that even with %indentlevel%, a more elaborate (external) scriptlet, for expanding by TWO levels instead of just one, would become extremely time-consuming, since, whilst for internal UR code, those attribs are available immediately, having to retrieve them, 1 by 1, by clipboard, is, whilst technically feasible, devoid of sense,

and indeed, writing a scriptlet for expanding a subtree by THREE levels would imply, for the third-level-part, the retrieval of the indentlevel attrib of any encountered item then, in order to check if the item is to be processed (since in level-minus-3), or if it's NOW just to be traveled-thru (since in level-minus-2), since then, the {right} would not expand anymore, but straight go to the first child-item, then then {up} would go to the item before, and thus, on second run, thus a macro (if it didn't also get the respective indentlevel of every traveled item except for its level-minus-2 part above) would immediately get stuck (and comparing item titles with previously stored-ones would also imply getting command-line attribs by clipboard 1-by-1, and it would be just slightly less time-consuming to retrieve the titles by other means (e.g. from the caption (!), since we would have to enlarge our "waits" (which AutoHotkey calls "sleeps"), to allow for the caption to change (but the retrieval from the caption, since available as AHK = Windows system attrib then, thus NOT needing the clipboard, would be much faster indeed).


In this context, it's worth mentioning that UR's status bar does currently NOT also mention indentlevel, but only childcount, parentcount and keywordcount, AND that its values can currently NOT be retrieved by AHK, so probably neither by other macro tools,

=====IMPORTANT=====
BUT if you could make available UR status bar info to external tools (you know AHK's "Window Spy" and the respective tool in the AutoIt set, of course), THEN, by adding the relevant attributes to the status bar - in case optionally, just as you do it currently with the command-line -, those attribs could be retrieved DIRECTLY, without the oh-so-time-consuming detour by clipboard!

In other words, as soon as you (technically) could provide some (compound) string (then to be, in no time with modern PC processors, to be analyzed / disaggregated back into their original (UR item attribute) components), "fetchable" for external scripting languages like AHK and AutoIt,...

THAT WOULD BE ALMOST AS GOOD AS A REAL API !!!!

I currently say, UR's the BEST tool of its kind (Mac included), but then, just incredible, additional scripting possibilities break thru, and UR's advance will become incredible! (cf. MS Word, Excel...)

As said / implied above, I currently refrain from writing an expand-by-3-or-even-4-levels scriplet just because of the need of retrieval of the necessary core info, 1-by-1 for every traveled item by clipboard (!), so that would take "minutes" (i.e. many, many seconds indeed) and thus becomes devoid of sense - if those necessary info became available "immediately", i.e. within 10, 20 ms each, INSTEAD of, currently, in 1, 1.2s each (to remain reliable that is!), it would just be(come) another hour (max) of additional scripting time.

THUS:

- Please consider an internal function "expand by 3 levels", ditto for 2 (!) levels (i.e. as above, but internally), and for 4 levels perhaps. (And then there is also the much simpler way, for really just 1 level, counted from the parent-item, i.e. without any loops / recursion, but with the "Tree-CollapseAll" before the simple, single {right}.)

- Please evaluate possible means to make available UR item attributes "direct" to the usual scripting languages (which are just "frontends", "wrappers" for the Windows internals anyway, so that should be possible in the end!?), or then, if that's not possible,

- Please evaluate the possible making available of the UR Status Bar info to external tools (just as are available other infos to them, e.g. the caption values, the control's names and order numbers, etc), and if that's possible,

- Please consider adding lots of UR attribs, by option, to to the Status Bar, just like you currently treat the command-line, so that we can get them from there, without the clipboard detour...

- And of course, all this would very largely justify an, and be a quite incredible, outstanding, leaving the competition far behind, UPGRADE!...


And please, of course, add "%childcount%" to the available command-line values, so we can retrieve %n% above! ;-)


EDIT:

1) For necessary clarity reasons, I renamed 1level to 2levels, and added a 1level, since I obviously had the siblings' list in mind, from which the above scriptlet expands 1-level indeed, but that wrong numbering (since we start from the parent item, so have to count from there) would have caused too much misunderstanding.

2) Obviously, the above-mentioned %childcount% would also serve as a (and thus not needed) "HasChildren" Y/N attrib, since childcount=0/n>0 would signal "HasNoChildren"/"HasChildren", respectively - often, that's the only info you'd need, but fast, and unfortunately, retrieval by clipboard isn't that fast at all...

3) A final external scriptlet - making sense when for every (traveled) item, indentlevel info also will be available directly, i.e. without delay - would have to be renamed to ExpandByLevels(n), n then being processed accordingy by the scriptlet's code, for the number of levels-down (1, 2, 3 or 4) to be displayed.