Page not rendering after postback

[Kalisto]

I have a simple .net page, with a button and a text box on it.

in the code behind I call a library function of mine that pulls some data from a database and displays it into the text box. (This piece of code works elsewhere on the site for the same piece of content)

On this one page, when the button is pressed it does a submit, and is supposed to add a date / time stamp to the text (textBox.Text = textBox.Text + DateTime.Now.ToString()).

However when the button is pressed all I get back is a blank screen. Putting break points in the code doesnt help, as they are hit when the page is first accessed, but as soon as the button is pressed, none of the break points are hit.

Any pointers as to what can cause this?
Cheers

K

 

[Kalisto]

Ignore me. As soon as I pressed send I had a blast of inspiration.

 

[TipGiver]

You can tell us what you did and fixed it. So others that browse that post can get benefit of your solution.

-TG

 

[Kalisto]

Oops, sorry. I was so happy I'd finally fixed it and I could switch the damn pc off and get some food!

Basically, in my Global.asax I had configured a redirect to an error page, where any exceptions were to be emailed to a configured email address, and the user sent to a friendly error message page. (The email address wasn't yet configured.) I knew all this code worked as I'd tested it. But I'd been lazy and just done response.redirect("errors.htm").

The page that was throwing the error was in a sub folder, that didnt have its own errors.htm page, so it appeared that the Global.asax page is catching the exception, but it is catching it in the sub folder, rather than at the application root. So rather than just go into an endless loop of throw exception because I cant find the page, which casues it to try and find the error page again, it just displays the original url, but a blank page. (I think that makes sense!)

And the reason that I wasn't catching any break points was that the exception was being thrown by a control seeing a piece of data wrapped in <> signs, so it was warning of potentially unsafe content, before any of the code behind was hit.

Hope all that makes sense!

K