2

So, we have some publishers in our department who have a passion for interlinking their MS Office documents (Word and Excel mainly) with relative hyperlinks. Then they publish them on our intranet website.

EDIT - I'm clarifying the issue cause the two answers missed the point.

  • In Excel and other Office documents, the hyperlinks are relatively pathed, and they do not include any explicit protocol.

  • When opened from the file system (Windows Explorer) these paths work (as expected).

  • When a hyperlink to this document is selected from a webpage, all browsers prompt the user to Open or Save the file. In all cases I am discussing here, the user is clicking "Open".

  • In Firefox, Chrome, and Opera, the Excel application is opened, and the relative links now use the file:// protocol and attempt to relative path from the cached copy. They are broken as expected, as the linked files do not exist in cache.

  • However, when opened from the Internet Explorer browser, the Excel client is launched, but floating over the hyperlinks, they are fully qualified addresses using the http:// protocol, as if the file was being served up by IIS like a web page.

So yes... it is something about the Micrsoft products (IIS, IE, and/or Office) and how they work together.

My question is How and Why would Excel be able to map the relatively pathed hyperlinks within itself to the fully qualified web address of where it was linked from?

Improve this question
8
  • On a side note. It is a relative link. By definition, a file opened off the Internet is going to have links relative to the Internet. Should a relative link not be a relative link?
    – surfasb
    Commented Dec 21, 2011 at 21:34
  • It's just possible that you might be going at this the wrong way. Save a webpage to the desktop and then open it. Click on those relative links. They are going to break like china.
    – surfasb
    Commented Dec 21, 2011 at 21:41
  • If you turn off ActiveX, you don't get this behavior.
    – surfasb
    Commented Dec 21, 2011 at 22:01
  • @surfasb you are repeating what I already know... relative links should always break when you move the source document without moving the targets with the same structure... I am trying to figure out why opening an Office doc in IE does not break as it should. I don't know how better to explain. ActiveX is not the issue because the browser is not using it, and there are no ActiveX controls on the HTML page. The magic, can't be entirely in Excel, or it would happen across all browsers. It is something in IE.
    – one.beat.consumer
    Commented Dec 21, 2011 at 22:33
  • You are right, it isn't specifically ActiveX. It looks like IE uses a Broswer Helper Object to open Office Documents. Disabling that isn't an idea situation as it makes the UX a bit clumsy. I was specifically trying to nail down which component differentiates IE's handling from Firefox/Chrome's. I'm personally surprised I've never run into this before. Possibly my predecessor did and fixed it. I'm almost certain I will run into this issue again and would like to see a resolution.
    – surfasb
    Commented Dec 21, 2011 at 23:10

2 Answers 2

Reset to default
1

Though the situation has nothing to do with Subversion, this is the closest answer I could find:

Some combination of Microsoft's "Office Document Cache Handler" browser helper object, and the WebDAV capabilities of the office documents and the web server.

https://serverfault.com/questions/301955/stopping-microsoft-office-2010-from-integrating-with-subversion-server-as-if-it

Also the relevant Microsoft support doc that is linked in the Serverfault question.

http://support.microsoft.com/kb/838028

Improve this answer
4
  • I haven't done any further testing, but I can reproduce your behavior off of a Sharepoint Server. But that is expected behavior in our case. Otherwise the crazy Excel charts people produce would break.Otherwise, we zip up the hierarchy of files.
    – surfasb
    Commented Dec 21, 2011 at 21:57
  • @one.beat.consumer, rather than edit an incorrect answer, post the correct answer yourself and you should be able to select that as the correct answer, removing the "Answered" tag from this one.
    – music2myear
    Commented Dec 22, 2011 at 18:24
  • @music2myear surfasb provided two answers to the scenario, the second one was correct, the first was incorrect. For clarity to other reasers, my edit was to remove the irrelevant incorrect portion and leave the correct answer up. The suggested edit is the right answer and what surfasb came up with which is why I marked it as correct. Please commit the edit.
    – one.beat.consumer
    Commented Dec 22, 2011 at 18:54
  • @surfasb has the ability to approve the edits made to his answer. I'll defer to him in this case. If he approves the edits there will be no issue.
    – music2myear
    Commented Dec 22, 2011 at 19:09
0

A URL, even one starting with file:// is still a URL and your default browser for URLs is set to Internet Explorer. I would try linking the file using \\servername\share\filepath\filename or DriveLetter:\filepath\filename.

Using Group Policies, you can set them to automatically map drive letters when logging onto their computer.

Improve this answer
1
  • -1 but I don't have the rep. I am a programmer; I know what a URL is and the different protocols. Read the question again. Referencing a UNC share is not an option here. The files exist within the web applications folder structure and will be linked via http from the page.
    – one.beat.consumer
    Commented Dec 21, 2011 at 19:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .