HyperLink Bug

T

tshad

I had posted this problem earlier and just noticed that the Hyperlink is the
problem.

Apparently, it doesn't figure out the path correctly. It uses the path of
the file it is in, even if it is a control.

I have 2 files "displayCompanyJobs.aspx" and "displayCompanyOverview.aspx"
which are in both the folder "/jobseeker/" and "/employer/".

I have a user control "displayCompanyJobs.ascx" that is in my /applicant/
folder.

I call www.stw.com/jobseeker/displayCompanyJobs.aspx, which will load the
user control /applicant/displayCompanyJobs.ascx. In my control, I have the
following lines:

<a href="displayCompanyOverview.aspx">anchor test</a><br>
<asp:Hyperlink ID="test" Text="HyperLinkTest"
NavigateUrl="displayCompanyOverview.aspx" runat="server"/><br>

Both will put a link on the page. But the links are different. When you
roll over the anchor (a href) it shows:

http://www.stw.com/JobSeeker/displayCompanyOverview.aspx which is correct.
That is where the aspx files are.

But if you roll over the Hyperlink you see:

http://www.stw.com/applicant/displayCompanyOverview.aspx which is not
correct.

If I call the .aspx page from the /employer/ folder:

www.stw.com/employer/displayCompanyJobs.aspx

When you roll over the anchor (a href) it shows:

http://www.stw.com/employer/displayCompanyOverview.aspx which is correct.
That is where the aspx files are.

But if you roll over the Hyperlink you see:

http://www.stw.com/applicant/displayCompanyOverview.aspx which is not
correct. So no matter where I call the control from the Hyperlinks will
always try to jump to the same folder as the Controls.

If all my controls are in one folder and my aspx pages are in a different
folder, you obviously want to go to the folder where the aspx files are.
Anchors (a href) and Response.Redirect do it correctly and Hyperlinks do
not.

This appears to be a bug since Hyperlinks translate into an link (anchor)
tag and you would expect it to work the same.

Why is this and is there a way around this.

Thanks,

Tom
 
M

Mark Fitzpatrick

This is not a bug. What you have not taken into account is the way a
hyperlink server control actually behaves, which is different from what you
are expecting. You can't compare it to a regular <a> html element since
there is absolutely nothing being done by the server on the <a> element.

The difference lies in the fact that the hyperlink server control is
attempting to keep the link relative to the user control. That means you'll
get a completely different path. It is doing it's job correctly because, if
you were just linking to an ordinary file and didn't need to have the server
control adjust the url, you wouldn't need it and could just use an <a> html
element.

When using a hyperlink control in a user control, you have to figure on how
to get the path as you would like it. I usually find writing it against the
application root poses the least problems. In this case, write it out by
using a ~/ at the beginning of the url such as: ~/mydirectory/mypage.aspx
and that will figure out the path relative to the root of the application
(remember, it's the root of the application, not the domain although if it's
also a root application they are the same).
 
P

Patrice

So it just look like that they kept the same behavior than for a page that
is if you say just "mylocation" in a link inside a usercontrol, ASP.NET
assumes that the location is relative to the location of what provides the
address (in this case the location of the ASCX control).

You could use code behind to provide your own address resolution...
 
T

tshad

Mark Fitzpatrick said:
This is not a bug. What you have not taken into account is the way a
hyperlink server control actually behaves, which is different from what
you are expecting. You can't compare it to a regular <a> html element
since there is absolutely nothing being done by the server on the <a>
element.

I agree that it isn't an said:
The difference lies in the fact that the hyperlink server control is
attempting to keep the link relative to the user control. That means
you'll get a completely different path. It is doing it's job correctly
because, if you were just linking to an ordinary file and didn't need to
have the server control adjust the url, you wouldn't need it and could
just use an <a> html element.

I also agree that it is trying to keep the link relative to the user
control. That is fine for images and buttons or textfiles that always in
the same folder. But that makes it useless for links to different pages
that are relative to the page you are in. The control is not the page you
are in. It is called by a page. Obviously the <a> tag and
Response.Redirect understand this.

It isn't doing its job correctly if it is figuring out paths if it is
handling the paths differently than everything else. In every other place
if I say url="display.aspx" it would assume that path is the same as the
original path of the page that called it. A control should not be using the
location of the control (otherwise since Hyperlink is a control why not use
the location of the Hyperlink control itself).

Here is the trace of the page:

PATH_INFO /JobSeeker/displayCompanyJobs.aspx
PATH_TRANSLATED C:\Inetpub\wwwroot\stw\JobSeeker\displayCompanyJobs.aspx
SCRIPT_NAME /JobSeeker/displayCompanyJobs.aspx
URL /JobSeeker/displayCompanyJobs.aspx

All the paths are the path of the page itself. Nowhere do you see
/applicant/

The only way I can figure out how to make this work is to change all my 50
pages or so that use a hyperlink and figure out where it came from (because
it can be different) and add that NavigationURL or change all my Hyperlinks
to LinkButtons and use the Response.Redirect to do it correctly. Both are a
pain.
When using a hyperlink control in a user control, you have to figure on
how to get the path as you would like it. I usually find writing it
against the application root poses the least problems. In this case, write
it out by using a ~/ at the beginning of the url such as:
~/mydirectory/mypage.aspx and that will figure out the path relative to
the root of the application (remember, it's the root of the application,
not the domain although if it's also a root application they are the
same).

And how do I do this from the control where mydirectory can be different.
How would I do it in my case where mydirectory is either /jobseeker/ or
/applicant/? I tried using the ~ like "~/displayCompanyOverview.aspx" and
of course it couldn't find it.

Thanks,

Tom
 
T

tshad

Patrice said:
So it just look like that they kept the same behavior than for a page that
is if you say just "mylocation" in a link inside a usercontrol, ASP.NET
assumes that the location is relative to the location of what provides the
address (in this case the location of the ASCX control).

You could use code behind to provide your own address resolution...

So you are agreeing that it is a bug.

I shouldn't have to do this. It should work like the Response.Redirect or
<a> in calculating paths, I would think. Otherwise, trying to keep straight
how to handle paths would be difficult - trying to figure out how to deal
with paths in one control over another. There is no consistancy here.

Thanks,

Tom
 
M

Mark Fitzpatrick

Tom,
A control should not be using the location of the control (otherwise since
Hyperlink is a control why not use the location of the Hyperlink control
itself).

That's not how it is. You are wanting it to be a certain way, but the .Net
Framework does not behave that way.
It isn't doing its job correctly if it is figuring out paths if it is
handling the paths differently than everything else. In every other place
if I say url="display.aspx" it would assume that path is the same as the
original path of the page that called it. A control should not be using
the location of the control (otherwise since Hyperlink is a control why
not use the location of the Hyperlink control itself).


It IS doing it's job correctly. You're making an assumption though on how
you expect it to behave, which is not correct. User controls keep liks
relative to them for a good reason, they are designed to be included in more
than one page. If I use a user control to contain a header graphic (or
similar element) for each and every page in my web site and need to maintain
a consitent behavior, I need the hyperlinks and image paths to be relative
to that particular user control and not the page.

You're also mixing control terminology. A Hyperlink is a control yes, but it
is not a User Control. A Hyperlink is a Server Control, which has a totally
different behavior and goal than a User Control, which is what you have.

Links and other elements need to be according to the container that they are
in. If you put a Hyperlink Control in a page, you expect it to be relative
to the page. If you put it into a User Control, you expect it to be relative
to the User Control.
If all my controls are in one folder and my aspx pages are in a different
folder, you obviously want to go to the folder where the aspx files are.
Anchors (a href) and Response.Redirect do it correctly and Hyperlinks do
not.

Anchors are not the same as a Hyperlink server control. A plain old <a>
element is not handled by your server at all and is, instead handled by the
browser. It's your browser that sends back a request for a file at a
particular location. The Response.Redirect does it as you are expecting
because it is an entirely different process all together. You can't compare
these two items to the behavior of the Hyperlink control, or any other
server control for that matter.

I can understand the frustration but you have to forget about the expected
behavior and figure out how and why it really behaves that way. That's the
way it behaves and there are darned good reasons for it to behave that way.
There are going to be a lot of things like this in the .Net Framework, but
you can't argue them away as bugs. This behavior has been in the Framework
since the 1.0 version and is still there for very, very good reasons. Give
some good examination for the reasons and once you have some more experience
working with them you'll find this behavior a very handy tool.


--
Hope this helps,
Mark Fitzpatrick
Microsoft FrontPage MVP 199?-2006. 2007 and beyond
 
P

Patrice

IMO the idea is that relative locations are relative to the element that
contains the link (that is relative to the user control location if the
relative location is included in a user control).

You could report this to connect.microsoft.com if you wish but IMO it looks
rather like a design decision that could be endlessly discussed than a bug
(I just said you could write some code, it doesn't imply writing code means
this is a bug).
 
T

tshad

I stand corrected.

I shouldn't have called it a bug. But I think that the behavior is not
consistant with other parts of the .Net Framework.

I also agree that Paths are different depending on use.

I know that if a control loads another control the path (when not absolute)
should be relative to the controls (as you say). Also, if loading a Graphic
I would assume that you would use something like: "/images/graphic.jpg" if
you have all your graphics in one location and if you want to use a Graphic
specific to that control and use "graphic.jpg", I would assume the graphic
would be in the same location as the control.

But when you are Hyperlinking to another page (Redirecting), I would assume
that "page.aspx" would mean that the path would be relative to the calling
page not the calling control. You absolutely cannot put all your controls
in one location, if you wanted to, and use relative paths. Now if this is
the behavior, which it appears to be, then I will have to deal with it as
you say.

As I mentioned below, you can't use the "~/mydirectory/mypage.aspx" if the
control can be called by pages in different locations. Or am I missing
something.

As far as I can tell, I will have to go to any page that has a Hyperlink on
it and change it to something like:

<asp:Hyperlink ID="test" Text="HyperLinkTest" NavigateUrl=<%#
request.ServerVariables("PATH_INFO").Substring(0,request.ServerVariables("PATH_INFO").LastIndexOf("/")+1)
& "displayCompanyOverview.aspx" %> runat="server"/><br>

But I can't get that to work either. It equates to:
/JobSeeker/displayCompanyOverview.aspx.

It doesn't show as a link but as just the text: HyperLinkTest.

Thanks,

Tom
 
T

tshad

Patrice said:
IMO the idea is that relative locations are relative to the element that
contains the link (that is relative to the user control location if the
relative location is included in a user control).

I agree if you are talking about controls loading other controls or controls
loading images. If relative, it should be relative to the control, as you
say.

But when jumping from page to page - paths should be relative to the page
(not the control).

Teemu mentioned (on another forum) that Hyperlink uses ResolveClientUrl to
get the path. And Microsoft says in
http://msdn2.microsoft.com/en-us/library/system.web.ui.control.resolveclienturl.aspx
that the path is relative to the current page (not the control).
Parameters
relativeUrl
A URL relative to the current page

I may be reading that wrong, but that is what it says and my trace shows the
paths of the page as the location of the .aspx page.
You could report this to connect.microsoft.com if you wish but IMO it
looks rather like a design decision that could be endlessly discussed than
a bug (I just said you could write some code, it doesn't imply writing
code means this is a bug).

I shouldn't have called it a bug. But, IMHO, I would call it a design flaw.

Thanks,

Tom
 
T

Teemu Keiski

There says on following that page

Note:
The URL returned by this method is relative to the folder containing
the source file in which the control is instantiated. Controls that inherit
this property, such as UserControl and MasterPage, will return a fully
qualified URL relative to the control.

--
Teemu Keiski
AspInsider, ASP.NET MVP
http://blogs.aspadvice.com/joteke
http://teemukeiski.net
 
T

tshad

Teemu Keiski said:
There says on following that page

Note:
The URL returned by this method is relative to the folder containing
the source file in which the control is instantiated. Controls that
inherit this property, such as UserControl and MasterPage, will return a
fully qualified URL relative to the control.

You're right, I didn't see that note.

So all my controls have to explicitly use the ServerVariables("PATH_INFO")
for my HyperLinks. I just have to figure out how to make it work.

Thanks,

Tom
 
T

tshad

I looked at it and actually tried what it mentioned:

string url = Page.ResolveClientUrl("~/Customers/Profile.aspx");

But get a message:

'System.Web.UI.Control.Private Function ResolveClientUrl(relativeUrl As
String) As String' is not accessible in this context because it is
'Private'.

I still have the problem that if this is how a Hyperlink works - to make a
generic control that uses Hyperlinks is going to be difficult when I can't
call it from different locations.

Thanks,

Tom
 
T

tshad

Teemu Keiski said:

I did try to play with these functions, but got the following error:
'System.Web.UI.Control.Private Function ResolveClientUrl(relativeUrl As
String) As String' is not accessible in this context because it is
'Private'.

This was when I tried to do the following:

dim test as String
test = Page.ResolveClientUrl("~/displayCompanyOverview.aspx")


It might if I can get it to work :)

Thanks,

Tom
 
T

tshad

Teemu Keiski said:
It is public in ASP.NEt 2.0 but probably private in previous versions. You
could try using Page.ResolveUrl in that case.

(just note the PRB: http://support.microsoft.com/kb/811641 if you face
issues with it)

Actually, that one works but it still doesn't solve my problem.

dim test as String
test = Page.ResolveUrl("~/displayCompanyOverview.aspx")
trace.warn("ResolveURL = " & test)

Gives me:

ResolveURL = /displayCompanyOverview.aspx

That doesn't help the problem of the .aspx file coming from 2 different
folders.

Thanks,

Tom
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,990
Messages
2,570,211
Members
46,796
Latest member
SteveBreed

Latest Threads

Top