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

[Spliff]

Already in my previous remarks re "Search results, even sorted by Lineage (!), NOT preserving tree order", I in particular mentioned the fact that UR's lineage sort orders "short before longer", but did not follow-up that observation, albeit being more or less sure that "working on that one" would RESOLVE the "tree-order scramble" phenomenon, at least in cases where the user, KNOWING about UR's limitations in this respect, would observe alphanumeric tree order (!) within the "upper" tree levels, in order to finally GET, more or less, tree-order preservation where they need it!

To make this perfectly clear: Even with (!) my suggestion here, the user will (!) have to observe alphanumeric tree order, in order to get tree-order preserving results, but they may combine ABC order with numbering, in order to obtain that, in any such order, e.g. ("going down" the indentation levels, and yes, the brilliant "Tree - Show - n levels" from last year will help the user enormously with obtaining such a strict order within their "upper" levels indeed!) first ABC, then ABC, then 1-9 (or 01-99 if needed), or first 1-9, then ABC, or first 1-9, then 1-9 again, then ABC only, etc., etc.

BUT in these conditions, the user will then be able to use a real tree, spanning several indentation levels, AND get tree-order-preserving search results, proof:

1) items in "Notes" (and yes, they are alphanumerically ordered, in order to achieve the desired results upon search): see screenshot

2) search ("limit search to selected item "Notes"): * = every item is to be included into the results
columns: lineage (sort by), and title
result: screenshot not needed (see 3/4)

3) copy the results to a text editor (^a, rightclick, "copy grid values")
> does not work as expected, since the result is
Title tab Lineage (not Lineage tab Title)
(= as if in the UR search results, I had not switched the columns... which I had done here for demonstration purposes only anyway since we know that this switch causes big problems in UR, albeit "Lineage then Title", for the user, is much more "natural" than the other way round)

4) thus, in the editor, (by regex) restitute the intended order
Lineage tab Title
then replace the tab by another "|":
in the editor, we have now "full-lineages" = including the titles (similar to file system's "path" vs. "fullpath"):
Lineage (with separator char "|" where it applies); here's the list:
(please note that this list exactly replicates (in its row order) what you see as UR's search results (2 above), just with an additional "|" within the lineage, and the title, columns;

we see that (since sorting was by lineage, shorter before longer, and thus, as expected) the tree order (albeit original tree observing alphanumeric sort) is not respected:

Notes
Notes|a
Notes|b
Notes|c
Notes|d
Notes|a|alpha
Notes|a|beta
Notes|a|delta
Notes|a|eta
Notes|a|beta|1
Notes|a|beta|2
Notes|b|alpha
Notes|b|beta
Notes|b|delta
Notes|b|eta
Notes|b|delta|1
Notes|b|delta|2
Notes|c|alpha
Notes|c|beta
Notes|c|delta
Notes|c|eta
Notes|d|alpha
Notes|d|beta
Notes|d|delta
Notes|d|eta

5) Now, in the editor, "Sort (lines) a-Z" (which means alphanumerically; I didn't try numbers above 10 but as said above, leading zeroes for 01...09 would cause numbers like 10, 11, 12 also being sorted correctly if needed), result list:

Notes
Notes|a
Notes|a|alpha
Notes|a|beta
Notes|a|beta|1
Notes|a|beta|2
Notes|a|delta
Notes|a|eta
Notes|b
Notes|b|alpha
Notes|b|beta
Notes|b|delta
Notes|b|delta|1
Notes|b|delta|2
Notes|b|eta
Notes|c
Notes|c|alpha
Notes|c|beta
Notes|c|delta
Notes|c|eta
Notes|d
Notes|d|alpha
Notes|d|beta
Notes|d|delta
Notes|d|eta

As we see, the alphanumeric tree order is preserved, by the search results being sorted - outside of UR here - by "FULLPATH", instead of just "naked-path".

I am sure it will be technically possible to add a "fulllineage" column (or whatever it's called), so that UR users can sort by that, and as implied, with proper categorizations / naming, and with the help of Tree-Show-n-levels, users will be perfectly able to amply profit from this column sort, even if their first-level titling is not alphanumerically ordered, example:

Root (0)
Project A (1)
Other Project (1)
__1 - Some Title (2)
____A - some subtree (3)
____B - some other subtree (3)
__2 - Some Other Title (2)
And Another Project (1)

Search in "Other Project" will give correctly ordered results 2 levels down in this example, even though it's also correct that on level 4 then (in this example), the items will not be listed in manual tree order but alphanumerically, too, since there is no (and will not be a) "weighted precedence" for ordering, so "by full path" will not only apply to n top levels, but to any level, so a secondary sort "by tree order" will never apply then; in other words:

The user will be well advised to alphanumerically order their titlings where needed (i.e. within their projects or other data bulks within their UR DB(s)), and "all the worse for the rest", i.e. for the deeper-down data of which the tree order will continue to be scrambled...

My suggestion thus will not entirely preserve tree order, BUT will preserve the tree construction, down to the user's "chapters": it'll be just within those "chapters" then that the user will have to be aware of their intended tree order not (also) to be preserved anymore.

It's core functionality we're discussing here, and if the competition doesn't get it, all the worse for them.

It's overdue, as well as v7 is then. ;-)

Spliff, you do not have permission to access this page. This could be due to one of several reasons:

Your user account may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?

If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.