I didn't describe what I was trying to do clearly it seems.
Sometimes postbacks occur when you change your dropdowns or select an item
from a listbox, etc. which probably changes some state on the page but not
necessarily commit to the backend - i.e. write to DB.
That said, I realize that's what postback event handlers are for such as
button click event handler. The only thing is that I was trying to do
without the postback event handler for a particular situation. So for
example, if you have a client side button or menu item that don't have wired
event handler for some reason and submits a client side form, what would be
the best way to know whether that form was submitted for "commit" or for
"state change"? Ok, maybe we're going back in time to ASP days but I was
just wondering.
Thanks all.
"Michael Ramey" <raterus@localhost> wrote in message
news:OX**************@TK2MSFTNGP10.phx.gbl...
There is a difference? From my experience, if I'm "postbacking", I always
have the intention of doing something. It's how you define the different
event handlers for the controls on your page that determines what happens.
And also checking for page.ispostback in page_load to make sure you don't
repeat whatever process your page goes through the first time it is
loaded.
HTH,
--Michael
"Jiho Han" <ji******@infinityinfo.com> wrote in message
news:Oe**************@TK2MSFTNGP09.phx.gbl... What is the best way to check whether the page is simply a postback or
the form has been submit with the intention of doing something?
In the olden days, I used to check for a form field name used for the
submit button:
<input type="submit" name="saverecord" value="push me to save">
Then I'd retrieve it using something like:
' pseudo code
If Request.Form("saverecord") <> "" Then
' do action
End If
How are you guys doing this?
Thanks for any insights.
Jiho