How to use the acrobat URL Protocol?

Resurrecting these threads years later so that this information is out there on the web SOMEwhere...

The problem itself is simple: 

• Application protocol URIs pass the *whole* URI as the argument, not just the part you expect to be a parameter.  So when you form a link `acrobat:my.pdf`, what comes into the `HKEY_CLASSES_ROOT\acrobat\shell\open\command` as `%1` isn't `my.pdf`, but `acrobat:my.pdf`.
• That's just how these have always worked, and apps that respond to them correctly have code to interpret that whole application URI properly, whereas it looks like acrobat (or at least, Reader DC 21.7.20099.454979, which is what I have access to at the moment) does not.  (Maybe that was the intent at some point of the `/u` switch that's also in that command reg_sz, which as far as I can see doesn't seem to do anything in the current version other than "pretend no argument was passed at all instead of erroring out about its format" 🙄)

Fixing this, however, was a bit of a pain. 

I want to be able to just set that reg_sz value on the target machines (perhaps via gpo or something), not have to have a wrapper file of any kind deployed on them to support it, so I had to figure out a way to get rid of the spurious `acrobat:` in the parameter just using a one-liner of whatever subset of windows shell syntax it would actually let me use... 

The result feels a bit idiosyncratic to me, as far as in-context usage of quote characters and late-bindings and lack of escaping and stuff are concerned, but this is verbatim what ended up working on Windows 10.18363.  YMMV, at the least depending on your acrobat executable path.

cmd /v:on /c "SET _invocation=%1 & "C:\program files\adobe\acrobat DC\acrobat\acrobat.exe" !_invocation:acrobat:=!"

So there that is......  

But uh, hey adobe, why don't you just, like, add the single line of code to actually support the `acrobat:` protocol you apparently insert into the windows registry...?  I was stunned to discover that Acrobat, even just Reader, smoothly handles editing PDFs directly in webDAV folders, including in SharePoint libraries with check-out/check-in functionality integrated right in - but only if you manually paste the URL into the file open dialog (or pass it as a command line parameter).  Letting web developers actually form the hyperlinks that would directly remotely open PDFs that way seems like a huge win, so why is this broken and undiscussed?

From my experience acrobat: protocol does not work for opening PDF documents. One option is to use third-party product that opens documents from a web page: WebDAV Ajax Library. It can open PDF files in Adobe Acrobat DC as well as any other docs - txt, rtf, odt and office docs in associated application.