|
#1
|
|||
|
|||
Some reminders and clarifications for the above:
Using 1 UR item for notes, and then referring to paragraphs, is not realistic since %anchor% will (=can) not be updated; even %item_path" will (=can) not be updated within the linking app, when you move the UR item within the original UR db (which is common procedure though), and contrary to %item% (i.e. the item's ID), which will remain stable as long as you don't move it into another db. (Also, in examples like my first one at least (I.e. flowchart elements and the like: multiple elements, with very tiny text length each), and where thus the "link" text should not get too much "prominence", both whole db paths, and whole item paths are horrible, visually; less so in large text bodies where your "link" could be the last line of some paragraph, obviously, perhaps [in italics, in brackets].) Therefore, and without saying that "deep links" should be avoided, it appears to me that instead, you should multiply UR items, instead of multiplying paragraphs within one UR item, then "link" to those items. In this context then, it should be noted that both run, d:\ur\0.db /item 23131 run, d:/ur/0.db /item 23131 just activate the db, whilst all three of run, "C:\Program Files\UltraRecall\UltraRecall.exe" "d:\ur\0.db" /item 23131 run, "C:\Program Files\UltraRecall\UltraRecall.exe" "d:/ur/0.db" /item 23131 run, "C:/Program Files/UltraRecall/UltraRecall.exe" "d:/ur/0.db" /item 23131 correctly activate the item; I prefer the classic syntax, and " 8.387" element suffixes (= mostly 3-digit IDs since "links" to, quite tiny, UR "project" files) in apps where real links to UR items are not possible, appear "bearable", in lack of anything better for these situations. Last edited by Spliff; 02-17-2024 at 02:17 AM. |
|
|