View Single Post
  #7  
Old 12-01-2023, 04:22 AM
Spliff Spliff is online now
Registered User
 
Join Date: 04-07-2021
Posts: 212
Thank you for the information. Have never used "safe mode", will No macro or script, no "clipboard manager" or something running.

1) ^x in tree is deemed, within UR (= target: same db or another db), to move the whole item (incl. content and other attributes); ^x or ^c in UR tree, with another application as target, is deemed to just copy/move the item title(s) - this is a big difference.

2) ^x in tree, from UR db to the SAME UR db, will not need to touch the content, but just reposition the item (ID) (^c is different here, content here will obviously have to be retrieved and rewritten to the new item(s), but I don't have experience with it)

3) Since UR doesn't know the target (same UR db, other UR db, external application) upon ^c/^x, all the necessary info is written into the clipboard, into those "codes": UltraRecall:Items, UltraRecall:TreeNodes, UltraRecall:ResourceLocatorW, etc. - all these are quite "cryptic" and, of course, your developer's secrets.

They will be used when needed (partly from UR db to the same UR db, full throttle from UR db to another UR db), and discarded when not needed (from UR tree to another application).

Thus, at the "^v moment" in any UR db, the UR has to check, and recognize (sic!), if the clipboard content is "ordinary" clipboard content, from either some UR content pane or some other application, OR from some UR tree.


Possible causes for problems:

a) Necessary cryptic-data not always correctly retrieved upon ^x (If there was not enough time / wait before switching to the other UR db, that would occur even more often for bulk operations, whilst for them, it has never occurred) (a: incl. possible third-party app interference)

b) Necessary cryptic-data not always correctly processed upon ^v if ^v is triggered in another UR db (which are named .db, not .urd, but a problem caused by not systematic recognition of the target as also being a UR db should occur both for 1- and multiple-items pastes) (b: also incl. possible third-party app interference)


Will run "Free Clipboard Viewer" systematically, minimized

I have not being able to produce the phenomenon with my tries, so if the problem occurs again, it will show if a) is the problem, or if also the cryptic-data has correctly been put into clipboard, but b) the processing at ^v is at fault.

Will then report back. (No idea why in regular use, problem occurs in > 50 p.c. of cases, whilst now, not once... will check running programs then which might not run now indeed!)
Reply With Quote