I wanted to add something to Mark's post.
First, there is rarely a time when you use IsPostBack. !IsPostBack is
common, as you are first painting the page, but IsPostBack only leads you to
problems. You end up with something like this:
if(!IsPostBack)
{
//Code to paint page initially
}
else
{
if (button1.Click)
{}
else if (button2.Click)
{}
else
{}
}
You then find you are in spaghetti land.
Second, you have evens for each button. Use them.
Third, it is a good practice to separate function, in properly named
routines, from event handlers and methods. Not only does it make intent
clear, but it has an extra bonus if you ever have to obfuscate: None of your
code is easily accessible to those attempting to reverse engineer.
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
*************************************************
| Think outside the box!
|
*************************************************
"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:OY**************@TK2MSFTNGP05.phx.gbl...
I'm trying to get a good understanding of this.
I have a page that is fairly complex and makes a number of database
accesses. I'd love to cache it but, since the data will be specific to the
user's current settings, that doesn't really seem to be a useful option.
I also have a button that should change some data and then refresh the
page.
The problems are:
1) The entire page rebuilds in the load event before the button handler is
called. I know I can test IsPostBack, but when the data changes, I really
need to rebuild the entire page.
2) Since the page has already been build when the button handler is
called, changing the data has no effect.
It almost seems like it would be better if the button handler was called
first. At any rate, I'm just wondering if some of you have dealt much with
this quirk and how best to deal with it.
Thanks.
--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
