Inbound links (to specific items) do not work

[kinook]

The application which allows for external linking must not be handling the link properly.

When I launch a UR link like

ur://D:/Temp/test.urd?item=1026,1006,1000&pos=5954

in the Windows Run dialog, UR is launched to open the DB and navigate to that item and position within it.

This also works when entering the link into a browser such as Edge (after a prompt about a web site wanting to open an application), Windows Explorer, etc.

This is standard Windows functionality that is being leveraged and will work in any Windows application that properly calls ShellExecute API or similar.

https://stackoverflow.com/a/38205984/156738

[Spliff]

Thank you for your clarifications. Problem is not resolvable it seems.

AHK is not involved: Problem remains, identically, when I run Windows (fresh re-start) without starting AHK, my AHK script not being autorun anyway; and I also checked the path variables to no avail.

The third-party app is Scapple (originally a Mac app, ported to Windows, and they give a heck about Windows (users)), and there is no path setting (let alone for links) in that program, and it obviously does NOT understand UR's special link format: as soon as there is the leading "ur:", it tries some "relative" path construction, and without the leading "ur:", UR doesn't understand the "item info" anymore (in links; hence my post/code in the other other forum thread linked above, for "runs", which then seem to be the only solution currently).

With the leading "ur:", I got many error messages from UR, but which I hadn't see before posting, because they had been hidden by my other windows, and had vanished when I had been forced to "end" UR, by having made so many tries that UR became unresponsive.

Those UR error messages clarified the problem: They read, for the above UR db link strings (e.g. ur://D:/UR/1.db, "Error opening db: C:\Program Files\Scapple\d\UR\1.db[etc here if I add the item info in the "link"] - File doesn't exist.", so when the link string doesn't have the usual format, Scapple tries to "translate" the link then, into something unusable, instead of just sending it.

Scapple stores in xml, and the xml data seems to be correct, they scramble it afterwards:

<Notes>
<Note Position="385.2,115.7" ID="0" FontSize="12" Width="156.25">
<Appearance>
<Alignment>Left</Alignment>
<Border Style="Rounded" Weight="0"/>
</Appearance>
<Formatting>
<FormatRange Underline="Yes" Link="D:/UR/1.db">29,5</FormatRange>
<FormatRange Underline="Yes" Link="ur://D:/UR/1.db">36,5</FormatRange>
<FormatRange Underline="Yes" Link="ur://D:/UR/1.db?item=4379,4335,4334,1000&amp;pos=0">43,5</FormatRange>
<FormatRange Underline="Yes" Link="ur://D:\UR\1.db?item=4379,4335,4334,1000&amp;pos=0">50, 5</FormatRange>
<FormatRange Underline="Yes" Link="D:/UR/1.db?item=4379,4335,4334,1000&amp;pos=0">57,5</FormatRange>
</Formatting>
<String>This is one item with links: link1, link2, link3, link4, link5.</String>
</Note>
</Notes>

Thus (and since the "which Scapple item is this" info is not available by any other means), the only solution I currently see, is:

add a space and then URdbname.URitemIDNumber (e.g. " 1.4379"; retrieval: see the other forum thread linked above; URdbPATH and URdbName instead if they ain't all within in the same folder anyway) behind the "regular" text of the Scapple item, then, to trigger that as a "run link", the whole Scapple item being selected:

send, ^c
clipwait, 3, 0
pos := instr(clipboard, a_space,, 0) ; last occ
s1 := substr(clipboard, pos+1) ; db and itemID
pos := instr(s1, ".",, 0) ; last occ again
s2 : substr(s1, pos+1) ; itemID
s1 := substr(s1, 1, pos-1) ; db

then you concatenate the run-string (see the other thread) together with its target strings s1 and s2, then
run, %runstring% ; complete example:
; run, "C:\Program Files\UltraRecall\UltraRecall.exe" "d:\ur\1.db" /item 4379

Even better, Kyle's suggestion, including the position/anchor info, example:
run, ur://D:/UR/1.db?item=4379`,4335`,4334`,1000&pos=300 ; in AHK, you'd need to escape the commata with "grave" accents

Thus: You would add: " 1.4379,4335,4334,1000.300" ; db.item_path.anchor
Then:

send, ^c
clipwait, 3, 0
pos := instr(clipboard, a_space,, 0) ; last occ
pos := instr(clipboard, " ",, 0) ; last occ
s1 := substr(clipboard, pos+1) ; db.itempath.anchor
pos := instr(s1, ".",, 0) ; last occ again
s3 := substr(s1, pos+1) ; anchor/position
s2 := substr(s1, 1, pos-1) ; db.itempath
pos := instr(s2, ".",, 0) ; last occ again
s1 := substr(s2, 1, pos-1) ; db
s2 := substr(s2, pos+1) ; itempath

then you concatenate the run-string (see the other thread) together with its target strings s1, and s2 and s3, then
run, %runstring% ; complete example:
; run, ur://D:/UR/1.db?item=4379`,4335`,4334`,1000&pos=300

This way, you can "link" Scapple items, or, similarly, any other paragraphs-or-whatever in ANY third-party app, to UR items; I would have hoped for some more streamlined solution, in a program which, like Scapple, pretends to provide outbound linking, obviously. ;-)

(ATTN: Code edited for typos.)

[Spliff]

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.