Two problems (not bugs) when more than one item is selected

[Spliff]

I don't want wrong info of mine to remain here, when I select one or several tree items, then ^c in tree, then ^v in editor (e.g. Notepad++), I get the naked titles, separated, if several ones, by crlf's in-between; the other metadata (cf. your post some months ago re (the) clipboard analysis (tool) obviously being withheld, and any content-data NOT being included.

Thus, the copy/cut part (^c/^x) is not the problem, but done almost instantly, and AHK's (thus unneeded) clipwait, be it just for text data or "any data", both take the whole max delay, obviously because the AHK commands do not correctly grasp the "hidden" meta data, visible by the tool alleged to above.

(My "items selected" check thus is not needed but can be replaced by a faster "lf" count within the clipboard, result 0 meaning 1 item, and so on.)

Then, and, as said, I'm positive, upon (even "internal" = within the same db) item moves, upon "arrival" (= ^v), the item(s)' content data is (unneededly) re-written, so the user's problem is, "what delay will have to be provided for the insert (^v) part", caused by that insert not only re-writing the meta-data but also the content-data (which may be quite big in case, and for example, this content data NOT also being within the clipboard, any try to count the clipboard's charcount, then to decide upon the allegedly necessary delay, will be devoid of sense) - and, as mentioned above, a Dll call instead, unfortunately, is quite unreliable, even though it seems that more often than not - but far from always - it seems to provide some help indeed.

Active* UR users might thus think of using a ramdisk for processing "item management" (i.e. shuffling around items / sub-trees), then (hopefully before ending the session, or before current loss, or before any other "fatal" problem) re-write the changed ramdisk db back to ssd/hdd (where it should be said that (regular, not per-ramdisk) ssd use for the UR db(s) might result in quite some wear, but that's another subject); from my experience, I can say that this works much better, but I obviously can't and won't be held responsible for data losses of other users, I just can't, and won't complain, of mine.

(Obviously, similar actions, upon the file system (folders, files: moves within the same drive, obviously) are processed without problems, since technically, they work upon the SFT (or was it FST or whatever, doesn't matter), leaving alone the files' content.)

And it's clear as day that the "hopping around" of the tree ("Data Explorer") representation on screen, on active* UR use, and which has never been really addressed (you once marked a version with a mention that the problem had been resolved, but unfortunately, I never could even observe an amelioration?), makes active use really unwieldy, in the sense that the user never knows, before doing a copy, move, or creation of a new (sibling or child) item, what the tree representation will do: new item jumps to first-visible-one ("scroll to top") or then not, sudden expansion of the moved item, or not, or even just of some parts of it, and even sudden expansion of sub-structures not-affected by the move, or by the new-item creation (!): It's all technically bearable in the end (i.e. can't be qualified as "bugs"), but it's visual clutter with no end, and thus, it incites the user who's bothered by it, to re-collapse the structures expanded-out-of-nowhere (and without any intelligible reason), to then manually re-arrange it all, into an orderly, neat tree representation, as intended by them... instead of the user being able to do real work instead - and yes, going to the list's parent-item, then doing "Scroll-to-top" is just 2 keys (or 2 key combinations), but having it to do again, and again, and again, for correcting UR's unwanted tree jumps, becomes really, really unwieldy in the end (obviously, the problem doesn't arise when the "rest" of the tree is too short for allowing UR's such jumping around, but otherwise, it's as unpredictable as the rest of the aleatoric, unwanted sub-tree expansions and all).

And even the (very frequent, but not systematic) "scroll to top" of newly-created items is not (!) wanted, most of the time, since the user might want to create quite a list of new items or even not, BUT might want the existent siblings of the new item NOT to vanish from view anyway, in order to continue to "work on them", or, if they are adding several items, in order to very which new items are needed, and, for short lists (=sets of siblings), it comes even handy if the paren (!) item of the list "stays on-top" (i.e. as first visible item), without any further automatic "scrolls to top" of other items, hiding it again and again.**

Thus, DOING AWAY with this all this unwanted "tree hopping" upon user-sided changes (moves, additions...) would make UR's appearance much more "professional" (see the caption) indeed.

*=by active users, active use, I understand shuffling around things, instead of just adding new elements, i.e. "active work", vs. "data repository"; obviously, users may be quite active in - and thus relying on - searching instead, but, obviously again, UR 's storage paradigm might be called rather "location-bound" than "string-bound", so relying on search, and refraining from "exact filing" (since that might become "too much fuss") would not really "follow the tool's purpose", all the less so since UR's reliable cloning (not only of items, but of whole sub-structures), in theory, makes "exact filing" possible.

**=And that's why, for example, not even counting the moved items, in order to get back to the user's previous tree location, after a move, works as expected, since the number of necessary "GoBack"s is totally aleatoric: if the moved "items' set" contain "children", that one might be unwantedly expanded "upon arrival" (and then, or anyway (because of the user's navigation to them within the original location, that is), but to what extent, will have to be (in part) counted for the "GoBack" number, or not, and even the target structure in itself might be expanded (or not) upon move of the new child, or child set, and if the move expands it, there will be additional steps to "GoBack", totally unpredictable, too, i.e. target parent item A (collapsed) already has some children B, C, then the move of item Z (with or without some "children") expands A, and then, or not, even some of the children B, C... appear in the "GoBack" list, and thus will have to be counted in order into the correct number of "GoBack"s, in order to go, after the move, back to the previous user location:

Where the user might have done a previous step, {down}, in order to put such a "go back target" into the "go back list": All this is currently perfectly impossible, thus my suggestion to implement some additional code lines which automatically, programmatically (!) identify that "item below the move set", independently of any visual clutter... whilst the latter problem should finally be addressed, in such an, in most respects, very "mature" software (if we leave out the missing tree-order preservation in Search, the functionality's absence in the "competition" not being a valid argument for its non-implementation, but that, obviously, is just me).