|
There is an underlying problem; I hadn't make the connection up to this morning; there seems to be a more general UR clipboard delay problem with my UR installation.
(As said before, my UR DBs are on "WD Red Plus" HDD drive, with regular defrag (not of the whole drive, there is too much "traffic" to make that reasonable since it's, except for UR, my general "inbox", BUT regular defrag of the UR DBs (as said before, my O&O Defrag, and possibly some other defrag programs, make that possible; "Red Plus" means the HDD write the traditional way, so the HDD is not the culprit, and anyway, I have the problems described just in UR.)
A = the Above-mentioned (1-item transfer) problem
B = the above-mentioned Bulk transfer (seemingly no problem)
C = the (not-yet mentioned) systematic (sic! on my system) Content-copy/cut problem
A
Obviously, I do the ^x when tree has focus. Then, UR does not know if the transfer is made within the same UR db, to another UR db, or to a third-party program, so it has to put the whole data set into clipboard; obviously, this takes some time.
Of interest here: Whenever the transfer (cut-paste) of the item is done within the same UR db, the A problem doesn't occur: why? Obviously, because the (correctly existent or not correctly existent) clipboard content-pane data is not needed, but UR just triggers the necessary sql commands to update the parentage of the item in question, so even if the clipboard content is not correct, this doesn't show.
On the other hand, in more than 50 p.c. of the cases of A (= transfer to another UR db), the "Content" field content is lost; of course, in-between, I must change the db, by mouse click or by macro, but the macro doesn't involve any clipboard access.
Now it's possible - I'm not sure - that there is a delay problem: If after the ^x in the tree, I wait some seconds before changing the db, the results may be better than if I follow a regular workflow, meaning doing it "naturally", not "speedily" but not waiting on purpose (see C below to compare).
The amount of the content in that item seemingly does not play a role, i.e. the problem occurs independently of the content just being some words, some paragraphs easily readable on screen without scrolling, or more extensive content.
B
Since the problem seemingly does never occur in bulk transfer, I assume - I may be wrong - that internally in UR, the ^x in the tree, when more than just one item is selected, triggers another routine, NOT immediately putting all selected content into clipboard, but just "marking" the items for further processing; the same would be true for ^c, for both cases (= just one item, or multiple items).
Since then, when I press ^v within the target db, even whole sub-trees with dozens of items seem to be flawlessly copied / transferred, always, and which is obviously in contradiction with the A problem where such a transfer often isn't correctly done "even" for a single item.
Thus, I assume that bulk is not done by ^c/^x isn't done by putting the whole set into clipboard, then waiting for what may be wanted then, but it's the ^v only, in the target UR db, which then triggers the copying of the whole set.
As said, I may be wrong with that assumption, but whilst nobody would be surprised if it was the other way round: 1 item flawless, bulk = problem, the A problem (bulk flawless, but single items = problematic) is quite surprising indeed.
C
Not mentioned yet, but systematic (sic!) in my UR installation: Whenever I copy/cut something from another application TO the "current" content-field in UR, that's flawless, be it some words or some paragraphs... with the unique exception of "web import", where indeed, depending on the underlying source code of the page from which I do the select and then copy, the clipboard may indeed remain empty if I hadn't waited some seconds between the select (by mouse with shift), and then the ^c (in the browser); so these occasional web problems have nothing to do with UR indeed.
On the other hand, in any non-browser/web application, any text selection plus then ^c works instantly, be it just some words, be it several paragraphs, or more, there is no delay to be observed between the selection and the ^c, and then, after the ^c, the clipboard seems to be filled almost instantly.
Not so in UR: Whenever a UR content-field is my source, not my target, I systematically (sic! i.e. in all cases!) have to observe a wait of several seconds (3, 4) between the select (again by shift-mouse) and the ^c; if I do not observe that necessary wait, I can be sure that my ^v in the target application will either do nothing (= empty clipboard), or, according to the situation, will paste the previous clipboard content into the target (= clipboard content not being updated by the ^c in UR); the same is true is source AND target are the content panes of different items, be they within the same UR db, or in different ones.
Needless to say I thoroughly checked any possible macro interference, but there is none, I don't have any macro interception a ^c/^x, and when no script is running, it's the same delay I must observe in order to get, as said, even just some 2, 3 words of non-formatted text into the clipboard, from within UR.
I have come to live with that, but I'm not entirely happy with it. ;-)
Hence, comparing A, B and C, my assumption that A and C may linked by some underlying UR-to-clipboard problem, whilst B overrides that in some way.
|