Link to home
Start Free TrialLog in
Avatar of AaronReams
AaronReams

asked on

Response.Redirect redirecting to same page when using anchors

Hi Experts!

I'm not very familiar with ASP.NET but I'm figuring things out as I go...

This is probably easiest to explain if I list the flow...

1) source.aspx calls Response.Redirect("destination.aspx");
2) Button click in destination.aspx calls Response.Redirect("source.aspx");
3) Redirected back to original page ok.

Now here's the problem:

1) source.aspx calls Response.Redirect("destination.aspx#summary");
2) Button click in destination.aspx calls Response.Redirect("source.aspx");
3) Actually redirected back to destination.aspx
4) Another button click in destination.aspx again calls Response.Redirect("source.aspx");
5) Now I'm finally redirected back to source.aspx.

Does anyone know why this happens and how I force it to return to source.aspx on the first redirect?  I tried Response.Clear() to no avail.   hmmm.

Thanks in advance!
-Aaron

Avatar of hismightiness
hismightiness

Are there any existing or cached variables in source.aspx that would route you back to destination.aspx on the first button click?
Avatar of AaronReams

ASKER

I'm not sure I understand your question...  Can you explain?  Thx -Aaron
Well, without having any code snippets, one should assume that the reason you are using a redirect in the background versus a hyperlink is to check for certain conditions, then redirect.  In order to meet those conditions, you might also be saving a variable for return in either cache, viewstate, cookie, etc.  If this variable is being unextectedly saved, it may explain why it appears that the first time the page is refreshed instead of redirected.  If you were redirected again when reaching the page you were supposed to reach, then you would see the result you are describing.  However, placing a single button on two pages and redirecting between the two via the click event works here just fine.
If you want more detailed answers to your questions, it would help everyone involved if you were to include code snippets of how the redirect is reached in the codebehind of each page.
Hmmm... regarding the background redirect vs. hyperlink...

Basically I have an account summary page with several different edit buttons.  Whenever the user clicks on any of the edit buttons it redirects to the account edit page.  The user can edit his information on that page and click finish, which redirects back to the summary page.   This all works fine except for when I use #anchor in the redirect url to the edit page.  When I use that, I have to click Finish twice to return to the summary page.

I can post sample code if need be... I was just wondering if there was something small I was overlooking when using Response.Redirect with a URL that contains an #anchor reference.   Should the scenario I mentioned typically just work correctly?

Thanks your mightiness!  ;-)

Cheers,
Aaron
If I remember correctly, in ASP the anchor in the URL did not work at all.  I have not tried or seen any docmentation on the use of it in ASP.Net apps.  That, being said there are alternative ways to do "anchor" to a position in the page.  I use a querystring here to determine whether or not to go to an anchor point (which can be sent via Redirect).

http://www.mattkruse.com/javascript/anchorposition/
SOLUTION
Avatar of Rejojohny
Rejojohny
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Rejojohny, we do not know enough details about this persons project to just assume that there are not external elements like shared variables or classes saving values that may be part of a redirect condition - therefore I brough it up.  Surely, an expert of your level can understand that.

That javascript will only work on form controls (as long as they are visible), not other HTML elements.  I had to do something very similar with a Tech Support application recently and that link above was a life saver.
>>there are not external elements like shared variables or classes saving values
but what has these got to do with a redirect not happening ..
do u mean to say the redirect may be based on specific conditions??If so, wouldn't the same condition still exist when he removes the anchor statement from the redirect ...
(the user can edit his information on that page and click finish, which redirects back to the summary page.   This all works fine except for when I use #anchor in the redirect url to the edit page.  )
so shouldn't the redirect fail here too ...
>> Surely, an expert of your level can understand that.
 am sorry, but am not able to understand what you are trying to explain ..

anyway Aaron, it would ne nice if you could explain the purpose of the whole excercise .. maybe one of us can suggest an alternative ..
Thanks for both of your responses.

Here are more details on my current project.

The user can view their account information all condensed onto one page that I call a summary page.  The summary page has edit buttons near each different piece of information (details, billing, shipping, etc).

I have one other long page where they can edit the actual information.   I call this my edit page.  The edit page has a bunch of textboxes and several finish buttons all of which redirect back to the summary page (after I store the info in my db of course).  Currently I don't perform any validation on the data.  I just store it in the DB and redirect back to the summary page.

So, on the summary page if you click the edit button near the details section it does a Response.Redirect("edit.aspx");  That takes you to the edit page where I can edit some details and hit any of the finish buttons.  In the finish button handler I save info to the DB and call Response.Redirect("summary.aspx").  That works correctly (I'm taken back to summary page).

However, on the summary page if I click the edit button near say billing I do a Response.Redirect("edit.aspx#billing");  That takes me to the edit page correctly scrolled to the billing section. But, when I click the finish button and call Response.Redirect("summary.aspx"); I actually end up back at "edit.aspx" (without the #billing).  If I hit Finish again then I'm taken back to "summary.aspx".

So, is there a better way to do this?  Do I need to use Javascript?

Thanks for all the help!!

Aaron




ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Sweet!  That looks like what I need, so I'll give it a shot and get back to you later today.  Many thanx! -A.R.
Thanks for the answer.  It worked but the only problem is that it doesn't scroll the control with focus to the top of the viewable browser area.  Do you have suggestions on how to get the control with focus to align with the top of the browser window?

Cheers,
Aaron
If it is not aligning with the top of the window, the problem more likely is that there is not enough of the page below the control to continue scrolling the page.  A solution would be to add extra line breaks at the bottom of the page.
There is definitely enough room at the bottom of the page because this was all scrolling to the correct position when I used #anchors.  And it is scrolling to the correct control, but it scrolls the minimum amount to show the control (i.e. bottom of the page).  The desirable thing would be to have the control at the top of page.  If you can think of something offhand that'd be great, but if not thanks for the help and I'll post another question to EE later.  Cheers mate -Aaron
Oh, I see... You are just focusing now...  Well, the way I got around this was through the use of the Tutorial example here:

http://www.mattkruse.com/javascript/anchorposition/

The exact position that the page is scrolled to is dependant on the brower you are using, but for the most part you will see the behavior you have described unless some additional JavaScript is used to enhance the focus() function (like in the link above).
Great, many thanks! -A.R