Response.Redirect not working?

I have a small website that has a single MasterPage and a handful of Content Pages. My MP contains an asp:Menu item where all the subsequent CP's are called from. My problem is, when I issue a Response.Redirect command, it will first throw an exception ("Unable to evaluate expression") but then return to where it issued the statement and load the page. I don't understand MP's very well. Here is my code below:

Code:

---

    Private Sub Menu1_MenuItemClick(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.MenuEventArgs) Handles Menu1.MenuItemClick
        Try
            Select Case e.Item.Value
                Case "mnuCustomerMaintenance"
                    Response.Redirect("~/Customer/Customer.aspx")
                Case "mnuViewCustomers"
                    Session("disableButtons") = True
                    Response.Redirect("~/Customer/Customer.aspx")
                Case "mnuLogin"
                    Response.Redirect("~/Admin/SysLogin.aspx")            End Select

        Catch ex As Exception
            lblMessage.Text = dbIO.DisplayError("Menu1_MenuItemClick()", "SiteMP", ex.Message)
        End Try
    End Sub

---

The Red highlighted line of code executes and then immediately takes the Catch route but doesn't display the error (lblMessage is a Label control on my MP). I only see the error while running thru the debugger.

Please help!

Does this happen with just the mnuLogin menu or with all other menus?

Response.Redirect will send the current page to the browser along with a redirect request, so the browser can load the destination page. So please keep in mind the current page will be sent to the browser before the SysLogin.aspx page is sent. If there's any error in your current page, either in the code behind or in the aspx, you may get an error.

Try replacing the Response.Redirect with a Server.Transfer. Though they both are not identical, a Server.Transfer should terminate the current page and directly load the destination page from the server itself. This might help finding out if your current page has a problem.

.

HoneyBee,

The Server.Transfer command worked perfectly. It didn't even take the Catch path of the Try Catch construct. I don't understand why the Response.Redirect does that though. The code is pretty straight forward too. But to answer your question in the prior post...it takes the Catch path on every Response.Redirect that's executed.

It might do well to check the aspx part of the page.

.

What would I need to check though? I'm pretty new to this kind of programming so plz forgive dumb questions.

Thanks,

Would it be possible for you to attach your source code here, maybe someone can have a look.

The reason I suspect your page is because in a Response.Redirect, the whole page will execute and its output sent to the browser, before the browser opens the redirected page. A Server.Transfer will abort the current page and simply execute the redirected page. Which is why if Response.Redirect is not working, there could be an issue in your existing page itself.

.

HoneyBee,

Here is my MasterPage as well as my Content Login Page (just the markup). If you need the code-behind, let me know!

Thanks,

Well, I can't see it in the post. Anyways, if you can put your whole project into a zip and upload it, someone can have a look at it.

I am not in office today so I won't be able to do that, at least not today.

.

I wish I could but I can't since it's work related! Thanks for taking a look though HoneyBee....I'll research it some more and see what I can come up with.

Blake,

Did I not read a similar post from you on this matter?

Have you tried using the second overload for the Response.Redirect method?

Gary

if I remember right (and it's possible I don't have it right) a .Redirect works by sending an HTTP redirect header to the browser... and if it's encountered in the middle of the page, it may cause problems.
Server.Transfer on the other hand, simply hands off processing to the new page.

-tg

Gary,

I probably have not but would it be the "Response.Redirect(page, true)" overload? If so, then I have tried this.

tg, you are right.

It actually raises an Exception, which is what I think Blake is seeing. The difference with the second overload is that it either tells the code to continue executing or not.

http://msdn.microsoft.com/en-us/library/a8wa7sdt.aspx

Yes, you would the second parameter to be true, to indicate you want to terminate the page. Out of curiousity then, to confirm my suspicion, take out the Try/Catch. What happens then?

Gary

Apologies for digging up this old thread, but I am having the exact same issue and have been unable to find a solution. The strange thing is - we're only seeing the issue when we run the app in debug from Visual Studio. When we build and publish the app to the server, it works fine. We have tried both Response.Redirect("page.aspx",True) and Response.Redirect("page.aspx",False) and neither work when we debug.

Also - we've tried replacing Response.Redirect with Server.Transfer - and that works in debug from Visual Studio, but it doesn't load the style template for the app. Anyone have any suggestions what else we can try?

That's because Response.Redirect and Server.Transfer are two completely different types of operation. A Response.Redirect actually sends an HTTP notification to the browser indicating that it should redirect itself to a new address location. A Server.Transfer on the other hand doesn't do this... it simple does what it sounds like it does, it transfers operation to a new page. It's similar to calling a sub... only it's a page... not just a simple sub. It then does NOT sent the HTTP notice to the browser that the "page" has changed. Huh... I see I'm repeating myself.

as to why the difference between the two encvironments? Beats me... Likely a configuration difference.

-tg

The main reason Response.Redirect might fail is because you have some other JavaScript errors on the page. You might only notice such effects while debugging depending if your browser setting tell it to ignore script errors. If you use any master pages I would look into the JavaScript that that page is generating and look from there.