popup not working

popup blocker could cause this

If the link actually calls JavaScript, which in turn loads the new page, it may well work when you click on it and let it load in the same window, but if you right-click and choose Open in New Window it would fail (because the new window doesn't have the JavaScript function that the link is trying to call).

After further study I need to revise this question.  The problem ONLY shows itself if the filename contains the # sign.

So this link works...
file://data/file123.pdf

But this link does not...
file://data/file#123.pdf

If, instead of loading in a new window (_blank) I load into the same window, both work.

gary

No need to re-post, I think I've got it.

That's because the hash is interpreted by the browser as meaning "open the file data/file and go to the bookmark named 123.pdf."  The hash needs to be URI encoded (as %23) so the browser will interpret it as a character in the path, and not as the name of a bookmark in the file.

e.g.
<a href="file://data/file%23123.pdf"></a>

In classic ASP you can use Server.URLEncode (http://msdn.microsoft.com/en-us/library/ms525738(v=VS.90).aspx) to encode file names to make them safe for use in a URL; in ASP.Net HttpServerUtility.UrlEncode (or Server.UrlEncode) (http://msdn.microsoft.com/en-us/library/system.web.httpserverutility.urlencode.aspx); on the client in JavaScript using the "escape()" function (http://msdn.microsoft.com/en-us/library/9yzah1fh(v=VS.94).aspx). Also make sure your URIs are well-formed, you can review http://en.wikipedia.org/wiki/File_URI_scheme for details.

Further, in my quick tests, "file://" URLs seem to only work for file types that Internet Explorer can natively display - like text, XML or HTML - but not file types that depend on a plugin, such as PDFs.  Also note that "file:///" URIs should be used only when accessing paths on the client, use "http://" URIs for files located on the web server.

tgerbert, thanks for the reply.  Let me give that a try and get back to you...

gary

tgerbert,

My file is a pdf.  You said that IE can only natively display XML or HTML files, but my code works just fine when I target the same window.  Opening it in a new window (_blank) is where it fails.  So I still don't see a solution to the problem.

gary

I said in my tests, it may very well work in your environment.

Nevertheless, my comments regarding the hash mark, and it's need to be encoded, are still valid and have nothing to do with being able to display a PDF in-browser using a "file://" URI.

Did you try making sure that your URL is valid in the first place (see the Wikipedia article I linked to above), and making sure the URLs are properly encoded using one of the methods I referred to?

Are these PDFs on the web server, or on the client computer? Are you using JavaScript to open them? Are you using ASP.Net? Can you post some example code to recreate the problem?

tgerbert,

I still cannot get this to work, regardless of encoding.  So that you can actually see what I'm dealing with, I created a screen capture video showing the problem...

http://www.youtube.com/watch?v=B2laqpStX9U&hd=1

gary

What you will see in the above video:

I created three test links, the first is raw (no encoding), the second using the URLEncode function, and the third using the Replace command. Only the first link works. Further note that it only works if I load the file into the same window. When I try to load it into a new window, it fails (due to truncation at the # sign).

Ah ha!  Now I get it. ;)

Seems Internet Explorer isn't handling "file:///" URLs correctly.  Instead of making your URL "\\server\share\test#file.pdf", using "file://server/c:/local/path/to/share/on/server/test%23file.pdf" might work.

Your best bet, though, will probably be to make the PDFs available via a web server, and use a standard "http://webserver/test%23file.pdf" URL.

tgerbert,

I'm off today, but will give your lastest suggestion a try on Monday.

thanks,
gary

tgerbert,

The alternate url approach didn't work.  And I am unable to take the webserver approach as I have no control over the target server in question (IIS is not even installed).

gary

Good idea, I was about to suggest something a little more involved. ;)

Accept your own response as the only answer.

I think you got the points assignment backwards - http:#a35234008 should get the 500 points.

Found my own workaround.