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