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