You may not think that this topic is worthy of a blog post, but I found the process interesting when the need for me to use Hyperlinks arose while working on a project.

The project, I decided, was going to use a Windows Presentation Foundation (WPF) Page to give the User easy access to a listing of documents which reside on a shared drive.  The Page would be viewed through the Users web browser (in this case IE6) and then navigate to the document they wanted by clicking on the Hyperlink.

Now you may be saying to yourself that this is a trivial task and, aside from design, all that was required was to add the link to the document in the NavigateUri Property of the Hyperlink.

Normally this would be the case, but due to the way that User Permissions were set up there was going to be two different possible Paths that the file could be found at depending on what permissions each user had.

Most users, of the application, when they open the shared drive they are pointed to a directory which resides in a directory of the root directory on the drive.  Those with special privileges get directed to a directory one step up from the normal users.   Due to the possibility of different paths I could not use Absolute paths, like the first two Uri’s in the examples above, because I couldn’t determine which user was accessing the page.  This left me with using Relative paths for the files.

Using Relative paths was fine to a degree if the files resided either in the same directory as the WPF Page or further down the directory tree of the directory the WPF Page was in.  In these cases I could use a path like the following.

The majority of the files, in the case of my project, were in different directories than the WPF Page itself and as such using the previous type of Relative paths was not an option.  The WPF page was in a directory of the shared drive and all the other documents that I wanted to link to resided in their own topically named directories.

What I needed to do was figure out how to navigate out of the WPF Page directory and into the other directories.

In the end the answer was relatively, sorry no pun intended, simple.

It turned out that to work up a directory tree for a Hyperlink you only need to add a full stop in front of the path for each directory up the directory tree you want to move up.

Adding one full stop to the front of the Path sets the directory to be the directory that the Page resides in.  So I could also use the following for a file in the same directory as the Page.

You could also use the same format for a file in a subdirectory.

If, for example, I wanted to link to a file in a sibling directory of the directory the Page resides in then I needed to two full stops to the front of the Relative path of the file.

As mentioned above, the first full stop sets the path to the directory that the Page resides in and each additional full stop moves one directory up the tree.

In the case of my application the two full stops took the path up to what most users would see as the root directory of the shared drive, after that it was just a case of adding the sub-directory, or sub-directories, and the file name to complete the link.