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.

[Spliff]

The user has to know their Tools-Options-Misc-CommandLineFormat:

a) Either you set it to something like
|ATTRIB|ATTRIB|ATTRIB| etc. (even leading and trailing "|" to ease up the scriptlet code),

then you must know and observe the order, and for the 3rd element e.g., you do (you JUST replace the single "3" here with the correct number):

; code 1, for 3rd element here:
pos1 := instr(clipboard, "|",,, 3) ; 3rd occurrence
pos2 := instr(clipboard, "|",, pos1+1) ; next occ after that
n := substr(clipboard, pos1+1, pos2-pos1-1)

b) Or you use (1-char) codes for your elements, then their order is irrelevant (to be preferred):
{eATTRIB}{aATTRIB}{mATTRIB} etc.

then you do either (third element again here):

; code 2, for element-code m here:
pos1 := instr(clipboard, "{m") ; unique occurrence
pos2 := instr(clipboard, "}",, pos1+1) ; next "}"
n := substr(clipboard, pos1+2, pos2-pos1-2)

or in just 1 line of code:

; code 3, for element-code m here:
pos := regexmatch(clipboard, "(?<=\{m).+?(?=\})", n)

(In both sub-alternatives, you JUST replace the single "m" with the correct code-char or code-number.)


THUS:

F12:: ExpandBy2Levels() ; or whatever shortkey

ExpandBy2Levels() ; to be triggered when respective sub-tree parent-item is selected
{ ; Begin of function
clipboard =
; clipwait, 5 ; up to 5s EDIT: DELETED: MISTAKE
sendevent, ^+i ; or whatever for Item-CopyItemCommandLine
clipwait, 5 ; up to 5s
; your adjusted special-code 1, 2 or 3 from above here:


; and then (as known from above):
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

; and finally, the loop with correct iteration number:
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

Copyright by Spliff-in-UR-forum, no re-publication outside of this forum, licensed for personal use even in commercial environments.

(Code EDITED)

[Spliff]

Kyle, could you please consider the add-on of %CHILDCOUNT% into UR's command line (=10m's coding time?), notwithstanding your relegating my thread into your "to be considered some day" category?

When PIM users get the ability to JUST see the core info (= the -1 level) of some subject (= {right}), AND ALSO the "immediate-but-lesser-core-info" (= the -2 level), BUT without being bothered by any "development" info (= currently by UR's Tree-ExpandAll), they will be able to do MUCH BETTER IM than they will ever have been able to do before; if they then are intellectually able to profit from their new possibilities, their so-called "workflow" will be enhanced by quite just some factor indeed I suppose.

[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).