Hi, I was wondering if it was possible to create a hyperlink to a local file when generating a report:
In my xlst style sheet I generate a hyperlink so, but when I click on it it fails to open the file. (I use file uri like file///C:\Pathtofile)
Translate
<a href="{@FullPath}">Path to File</a>
You need to use the file protocol to create a link to a local file. In your example you are almost correct but is missing ":" , so it should be something like file:///C:\Pathtofile.
Hi Romulus,
Sorry my question was unclear. I can create a hyperlink, the problem is you cannot open the file by clicking on it.
Here is what happens when I click the link on my PC: (In English, "This page cannot be displayed") (sorry my question I mistyped the file protocol, but it is correct in the xlst)
Is this an infragistics control? Basically I want the log file I created to open in the default text editor when you click the link.
The viewer is just the standard .net WebBrowser control. Your problem is that the report is not shown at all or that when you click the log file this message appears?
The viewer is just the standard .net WebBrowser control. Your problem is that the report is not shown at all or that when you click the log file this message appears?
Hi Romulus,
It's the latter, "that when you click the log file this message appears".
I figured out the problem. It is because there is Japanese characters in the filename.
I tried encoding the URL like below and a few other ways but no luck:
new Uri(fileName).AbsoluteUri
I think this is a limitation with the WebBrowser control perhaps.
It works as long as there are no special characters in the filename, so one workaround is to strip non-Ascii characters.
Hi Andreas,
Thanks for the help, but I already tried HttpUtility.UrlPathEncode with no luck.
According to https://blogs.msdn.microsoft.com/ie/2006/12/06/file-uris-in-windows/
<quote>Don’t use percent-encoded octets to represent non US-ASCII characters because, in file URIs, percent-encoded octets are interpreted as a byte in the user’s current codepage. The meaning of a URI containing percent-encoded octets for bytes outside of US-ASCII will change depending on the locale in which the document is viewed. Instead, to represent a non-US-ASCII character you should use that character directly in the encoding of the document in which you are writing the IRI.</quote>
However, I also tried only encoding spaces to %20 and leaving other non-ASCII characters untouched with no luck.