Inbound links (to specific items) do not work

[Spliff]

I've got a third-party application which allows for external linking:
I select some string, then ^k, then I have a dialog with input field, expected link format: drive:\path\filename.suffix (that's all, i.e. no file:// or file:/// or the like), but thankfully, it also accepts drive:/path/filename.suffix (/ insteasd of \).

D:/UR/1.db
> activates 1.db (as expected, ditto for D:\UR\1.db, of course)

D:/UR/1.db?item=4379,4335,4334,1000&pos=0
> does nothing though, neither for the same, without the &pos=0 part

ur://D:/UR/1.db?item=4379,4335,4334,1000&pos=0
> does nothing, or even:
> opens my browser (!) with the url
https://ur//D:%5CUR%5C1.db?item=4379,4335,4334,1000&pos=0
> error message from browser (obviously)

(I made a lot more tries, with somewhat other (faulty) syntax, all in vain.)

Obviously, the problem is caused by the fact that UR links need that special "ur://" prefix (!), which is not understood by third-party software; perhaps, if there was an alternative, but more "regular" UR link format, for inbound links, like
D:/UR/1.db?ur:item=4379,4335,4334,1000&pos=0
that could possibly help, since third-party software would see the path part (d:/UR/1.db here), and therefore process the link, as far as they are concerned, and UR would then process the UR part, indicated by the bolded "ur:" substring above? As said, the same, without that, doesn't do anything either, obviously because UR "needs" (?) that "ur:", currently as prefix (!).

On the other hand, the command line
run, "C:\Program Files\UltraRecall\UltraRecall.exe" "d:\ur\1.db" /item 4379
run from within AHK (!), works fine, except for the fact that "position" is not possible, so it just opens the item, but doesn't also set a cursor to some previously determined position

(also, an additional /search "attribute" (which is text within that page) does nothing, /search obviously meaning global search here, not item-specific search, and as such is not combineable with /item)

but as "link" from within the third-party app,
"C:\Program Files\UltraRecall\UltraRecall.exe" "d:\ur\1.db" /item 4379
doesn't work either.

Any ideas how to make this possible? (just to specific items, but I suppose that if that was made possible, additional specific positions would not be a problem anymore, anyway?)

(I haven't tried with other third-party apps, but most of them use some format file:// or similar, and then, UR's ur: prefix might possibly cause problems, there too?)


EDIT:

I forgot to mention that
D:/UR/1.db?item=4379
as "link" does not work either; we've got two different, internal UR "location findings" above: %ITEM_PATH% for links, and %ITEM% (which should be sufficient anyway) for command line triggering, so perhaps, some inbound link format, just using the ID, not the internal path, could help?

Also see https://www.kinook.com/Forum/showthread.php?t=5629 where I shared the code to trigger it by AHK "run", but that's not linking, i.e. using the in-built target-trigger functionality of the "source" app.

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