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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
Similar Threads
