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

[Spliff]

A)

When an item is selected in the tree, or in the search results list, its content is displayed in the content pane ("Item Details") (as expected, naturally); when more than one item is selected though, the "Details" display "n items selected".

This is "sub-standard" if the standard are numerous picture viewers / photo managers, perhaps even all of them (free or paid)?: When more than one photo (file) is selected, they always display the "last-selected" one within their display pane.

It would be highly preferable that UR adopted this (photo management) standard, since this would allow for selecting, or then even de-selecting in case, multiple items, while "checking" them to decide if they really should be in the user's selection or not (before moving or copying them "in bulk").

When the user de-selects their very last choice, UR's "Details" could then even become blank if there's a coding problem for the "Details"' display then to revert to the previous-last selected item; the next selection would then again displayed as expected, or the pane would remain blank, up to the move / copy, if the de-selection was the user's last action before ^x or ^c.

(The alternative being to assign a special, dedicated flag (even by the space-key in the tree or search results pane, similar to the mythical Norton Commander, or even today, optionally, in Total Commander) to the items to be copied or moved (to the same target, obviously), then only select those flagged items, for copying / moving (whilst in the Commanders, this second step, necessary in UR then, is included within the first one, obviously), and afterwards, here and then, to delete that special flag from all the items; the problem with this work-around being that the select-flag-assigning will kill any other flag, previously assigned to the items in question, since flags aren't combinable.)



B)

"Item - Item copy command line" (icc) uses the clipboard, and there is no (?) other way to retrieve the icc data which, from macro / script, would allow for not "blocking" the clipboard by this (e.g. in AHK it's possible to retrieve the data from the caption or from (even hidden) controls, directly, but for example, in UR, the status line can't be retrieved to begin with).

Thus, when the user wants to copy or move one item, and with particulars depending on the item's internal UR path (similar current-path analysis before copy / move is without any problem in file management), they will need to use the clipboard twice:
1) trigger icc, then analyze it (or write it into a macro/script variable, then analyze that var)
2) send ^c or ^x (i.e. put the item into the clipboard)

This is a little bit time-consuming (since even (1) needs the clipboard), but well.

The problem arises with two or more items (always understood, obviously, that they are - consecutive or non-consecutive "siblings", i.e. share the same "path"); you would expect the following procedure to be possible:

1) select the items (see problem A above)
2) trigger icc
3) ^c or ^x to put the items into the clipboard

Now what about (2) here? How would that be possible?

Currently, icc only works if just one item is selected; otherwise the clipboard remains empty.

Instead it could also work, on the very first item within the selection-list/array/whatever (be that "first" item the first-selected one, or the first in the internal list, by tree order, by numerical ID, by abc, whatever: considering that, as said, the user would have to be conscious of the fact that behavior "as expected" could only be provided if the selected items are "siblings", so the kind of order within the list / array is irrelevant)

Then, the process above would be perfectly doable:

(2) = trigger icc, then icc := clipboard, then analyze the macro / script var icc accordingly, then send ^c or ^x.

Notwithstanding the fact that an alternative mode of retrieval for the icc data, other than first put it into the clipboard, would ultimately be preferable, even putting the icc data into the clipboard, then retrieving it from there,

would solve the problem IF the icc function also put the icc data of any one of (more than one) selected items into the clipboard.


And it seems that fellow UR users really appreciate such "professional" enhancements, even whilst then, they prefer to write their own macros to apply them in their respective workflow. ;-)

[Spliff]

In case (B) is possible but not also (A):

While selecting additional items, the FIRST-selected item's title, etc. will stay to be displayed in UR window's caption, but perhaps retrieval of the icc of the LAST-selected item will be easiest? In the meanwhile:

wingettext, s, A
if ( strlen(s) < 200 AND instr(s, "items selected") ) ; should be fastest this way
{
; icc currently not available
; code for multi-selection here, or just to verify:
msgbox, Multiple items.
}
else
{
; code for single-selection, incl. trigger the icc to begin with, or just:
msgbox, Just one item.
}

[Spliff]

It should be noted in this respect (Problem B) that, a little bit divergent from what we had discussed earlier re "cut" and then "re-insert" (^x, ^v) within the same UR db, the total size of what the user will have selected before the ^x, will amply effect UR's needed time to then do the move (^v), and thus amply effect the needed time within macros, before that macro can revert to the vicinity of the previous location.

Obviously, this remark only applies to moves (^x) since for copies (^c), it's obvious that even the content (i.e. content text, perhaps formatted, perhaps incl. a picture) mus be "doubled", i.e. put into the clipboard, then put into UR's db (as double).

On the other hand, I don't really understand why the same phenomenon also affects ^x (to begin with), and then, especially, the following ^v (as said, within the same UR db), since it's obvious that then, just the "location" / "parenting" (= meta) data should need to be "updated" indeed, but any content data will have been preserved and thus is NOT in the need to be "updated" = to be written to the ssd / hdd again, too, but obviously, that's what UR does do indeed, and I'm positive about this since according to the content's (!) extent (of 1, 2, 3 items to be moved), I can foresee if my macros will fail or not, because of not enough time to be left for the content (!) move, too!

So I have even envisioned a "clipboard size" check, in order to allow for the time needed, for the ^v (sic!) (And Windows internals' use to check clipboard activity only work so-so-here, also unreliably.)

(The update of the "meta data" is not (!) causing the problem, since it also occurs with just one single item to be moved, but which contains lots of text, or even a pic, let alone several such pics (little screenshots, e.g. of tables and the like).)

To clarify: It's not the ^x part which seems to cause the problem (and I understand that the ^x part (since UR doesn't know if the target will be the same UR db, another UR db, or a third-party application) also puts the content into the clipboard),
but it seems that the ^v part is the problem here, triggering the (obviously unnecessary) writing-on-ssd/hdd of the moved item(s)' content, too, thereby causing the "move fails".

Considering that in the meanwhile, the content is held in the UR db's "Recycle Bin" (i.e. "update" of the "location / parentage" data by ^x), the re-writing of the content, by the following ^v, seems perfectly devoid of sense.

Thus, I suppose that the current code, on ^v, does not differentiate (enough!) between "some import here" and "db-internal item move", triggering the re-writing of the content, too, and which then causes the problem; on the other hand, since the "UR Recycle Bin" data is correctly updated (i.e. the "moved-selection"'s meta data is deleted from the Recycle Bin, and filled into the "new target parent" table, etc. (in other words, instead of a "copy" remaining in the Bin, a SECOND transfer of the data is done here, FROM the Bin, TO the target), it should be possible to avoid the content rewrite for internal (!) item moves.


P.S. This applies to such moves from within the "Data Explorer" (tree); the "Link-Move-Copy Items To" presenting lots of other problems, so at the end of the day, for moves I cannot use it (i.e. my joy before New Year's Eve had been very premature):

a) Font (much!) too tiny

b) Except for level 0 (and thus for the items on level 1), the current expansion level of any "sub-tree" is totally unpredictable for me, so it can not be used for automated moves, except for moves to level 1 as implied, since, at least when the user uses "markers" (e.g. leading dots) on level 1 only, the expansion states of different level 2, 3... etc. items in this dialog will not interfere; on the other hand, if the user uses (different, obviously) markers on levels 1 and 2, they can NOT be sure the move will be done correctly (except for visual and manual checking and processing the expansion states), since only the level-1 entries are available for sure, whilst even level-2 entries' visibility (i.e. level-1 entries' expansion states) seem to be aleatoric

( c) After a move from that dialog, the tree in the Data Explorer is updated (which is understandable), AND the focus is set to the root item in there; thus, the use of the Dialog (for moves) will make users lose their "current tree location", just as "items' moves from within the Data Explorer" do. )

ad b) It should be noted that this is worse than triggering moves from with the "Data Explorer", since in there, thanks to Tree-Sho-2Levels (triggered from the root item), we now can expand by exactly 2 levels, and when I then have different "markers" before my level1-, and level2-items, I can move items "blindly" and reliably - except for the above-described "delay for (unnecessary) content re-writing" problem that is.

Needless to say, problem (b) also applies to copies and links, so from the Dialog, the, too, have to be done "manually", after checking of the target is available (i.e. by expansion of its parentage).


P.S.2

As for the "go back to previous tree location after move" problem, addressed by me 3 years ago but never resolved:

I understand it's not obvious, since the user might select some items in (this) order:

some siblings in level 1
a
b (selection 4)
c
__csome (on level 2) (selection 2)
d (selection 1)
e (selection 3)
f
g
etc

Then ^x, so here:
a
c (without csome now)
f
g

Now, if ^x (or ^c) automatically "marked" the "following" item as "last location", in this example, that would have been item "e", which is included within the "block" to be moved,

BUT it should be possible to systematically "mark" the "very next visible item below the visually last item to be moved", upon ^x, and then, to make this "mark" a "Special Favorite", in order to be navigated back to, by the user (or the user's macro) by 1-key / key-combination.

In the example above, this would be item "f", independently of the user's "selection order", AND in order to make this easily feasible, code-wise, this "next visible item below the block" could be identified by this UR code, automatically triggered after the ^x:

1. get the IndentationLevels of the selection, identify the tiniest (here level 1)

2. get the TreeOrders of the selected items of that level (i.e. here of items b, d, e, here 1), identify the highest (obviously e in this example, e.g. "15")

3. get the ID of the sibling with that TreeOrder+1 (thus, get the ID of item 16 in the example range), or, if there is NO such further sibling, get the ID of the parent-item

4. put the identified "prev-target-id" into the "Special Favorite" var.

Done. Just another example of "several quick steps in the code, but a BIG step for the user", or "Complicate the code (just a little bit) for de-complicating the user's work (MUCH!)."


It should be noted that instead, the use of "Go-GoBack" / "Go-PreviousItem", even if the user scrupulously pays attention to "select the last (tree) item (as) last (one)", or as very first one, or even just selects ONE SINGLE item (but which has "children") is, unfortunately, a bad joke:

Since the number of needed "GoBacks", etc. will be totally unpredictable, since the move (or copy) will trigger, equally totally unpredictable, (sub-) tree expansions "on target", which will then determine the number of the needed "GoBacks" - this is a nightmare indeed. But its effects can be overcome by identifying the go-back-target upon ^x/^c, putting its ID into an internal var, and creating a command to jump (back) to the ID's item:

This would be a total relief for any UR user actively using UR, even if they don't use macros.

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