469,593 Members | 1,984 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,593 developers. It's quick & easy.

why some controls must set autopostback property to be true??

why need to set autopostback property to be true?? I know autopostback event
means to send the form to the server automatically.

I tried checkbox, checkbox list, radio button, and radio button list, and
they all need to set autopostback property to be true, in order to make the
event of the control fires.

I know this is the must, but I dont know why. Please advise!

Thanks!

Nov 18 '05 #1
8 9039
It is that way because more often then not you want to do
other things on the form prior to taking a trip to the
server and back. Said another way, more often then not
the requirement is not to do something immediately when
the user clicks on the checkbox.

More trips to the server the "poorer" your performance is.
-----Original Message-----
why need to set autopostback property to be true?? I know autopostback eventmeans to send the form to the server automatically.

I tried checkbox, checkbox list, radio button, and radio button list, andthey all need to set autopostback property to be true, in order to make theevent of the control fires.

I know this is the must, but I dont know why. Please advise!
Thanks!

.

Nov 18 '05 #2
Because by default they are not such form controls or HTML elements that
would post to the server. Only buttons are such by default. In HTML (if you
check the HTML that results from using these controls) these controls are
such HTML elements that won't cause posting to happen. So by using
AutoPostBack you tell the control, that it should itself cause a postback
when certain action occurs (checking a checkbox, changing a selection and so
on) and as a result this creates proper javascript events and functions to
be used so that postback happens.

To cause an event to happen on the server, you don't necessarily have to
have AutoPostBack=true for that specific control as long as there is some
other control that causes a postback. DIfference here is that when you have
AutoPostBack=true, the control can cause the postback itself without any
extra control (to cause the postback). If control does not have
AutoPostBack="true", it is dependant on other controls, to cause the
postback so that events are raised (on the server).

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist
"Matthew Louden" <ma*******@hotmail.com> wrote in message
news:uw**************@TK2MSFTNGP09.phx.gbl...
why need to set autopostback property to be true?? I know autopostback event means to send the form to the server automatically.

I tried checkbox, checkbox list, radio button, and radio button list, and
they all need to set autopostback property to be true, in order to make the event of the control fires.

I know this is the must, but I dont know why. Please advise!

Thanks!


Nov 18 '05 #3
Just as an interesting side-point:

If autopostback is false, and a postback is caused by another control
(say a button), events will be generated both for the checkbox and the
button, yes?

But in most code design this will lead to *two* databindings, since
the normal assumption is that only one event in generated per
postback.

Is there any way to tell which is the *last* control event to be
fired? and do the databind there?

It's almost as if we need a new event handler: AfterOtherEvents()

;)

John

"Teemu Keiski" <jo****@aspalliance.com> wrote in message news:<Ob**************@TK2MSFTNGP11.phx.gbl>...
Because by default they are not such form controls or HTML elements that
would post to the server. Only buttons are such by default. In HTML (if you
check the HTML that results from using these controls) these controls are
such HTML elements that won't cause posting to happen. So by using
AutoPostBack you tell the control, that it should itself cause a postback
when certain action occurs (checking a checkbox, changing a selection and so
on) and as a result this creates proper javascript events and functions to
be used so that postback happens.

To cause an event to happen on the server, you don't necessarily have to
have AutoPostBack=true for that specific control as long as there is some
other control that causes a postback. DIfference here is that when you have
AutoPostBack=true, the control can cause the postback itself without any
extra control (to cause the postback). If control does not have
AutoPostBack="true", it is dependant on other controls, to cause the
postback so that events are raised (on the server).

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist
"Matthew Louden" <ma*******@hotmail.com> wrote in message
news:uw**************@TK2MSFTNGP09.phx.gbl...
why need to set autopostback property to be true?? I know autopostback

event
means to send the form to the server automatically.

I tried checkbox, checkbox list, radio button, and radio button list, and
they all need to set autopostback property to be true, in order to make

the
event of the control fires.

I know this is the must, but I dont know why. Please advise!

Thanks!


Nov 18 '05 #4
"John Sparrow" <js******@ecclescollege.ac.uk> wrote in message
news:13**************************@posting.google.c om...
Just as an interesting side-point:

If autopostback is false, and a postback is caused by another control
(say a button), events will be generated both for the checkbox and the
button, yes?

But in most code design this will lead to *two* databindings, since
the normal assumption is that only one event in generated per
postback.
That's a very false assumption. There will be one event per control which
wishes to raise an event.
Is there any way to tell which is the *last* control event to be
fired? and do the databind there?

It's almost as if we need a new event handler: AfterOtherEvents()


I agree that we need an event for AfterPostBackEventsButBeforePreRender.
--
John Saunders
John.Saunders at SurfControl.com
Nov 18 '05 #5
As John explained, one event per control is are raised, and only one of them
is the event caused by a postback. In other words, only one control at a
time can cause a postback.

For example when you have page which has a CheckBox (AutoPostBack=False) and
a Button. In CheckBox's CheckedChanged event's handler is written
Response.Write("CheckBox_CheckedChanged") and in Button's Click
Response.Write("Button_Click")

1. You first check the checkbox
2. Cause as postback by clicking the button.
3. Output on the page is "CheckBox_CheckedChanged Button_Click"

If you don't (un)check the CheckBox and just click the Button, only
"Button_Click" is outputted. It means CheckChanged event is raised as state
of CheckBox changed, but Button's CLick event is raised because Button
caused the postback.

If you change it so that CheckBox has also AutoPostBAck="true", you always
get either "CheckBox_CheckedChanged" or "Button_Click" outputted, but not
both at the same time, because "touching" either of these controls causes a
postback and the event to be raised.

Hope this helped.

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist


"John Sparrow" <js******@ecclescollege.ac.uk> wrote in message
news:13**************************@posting.google.c om...
Just as an interesting side-point:

If autopostback is false, and a postback is caused by another control
(say a button), events will be generated both for the checkbox and the
button, yes?

But in most code design this will lead to *two* databindings, since
the normal assumption is that only one event in generated per
postback.

Is there any way to tell which is the *last* control event to be
fired? and do the databind there?

It's almost as if we need a new event handler: AfterOtherEvents()

;)

John

"Teemu Keiski" <jo****@aspalliance.com> wrote in message

news:<Ob**************@TK2MSFTNGP11.phx.gbl>...
Because by default they are not such form controls or HTML elements that
would post to the server. Only buttons are such by default. In HTML (if you check the HTML that results from using these controls) these controls are such HTML elements that won't cause posting to happen. So by using
AutoPostBack you tell the control, that it should itself cause a postback when certain action occurs (checking a checkbox, changing a selection and so on) and as a result this creates proper javascript events and functions to be used so that postback happens.

To cause an event to happen on the server, you don't necessarily have to
have AutoPostBack=true for that specific control as long as there is some other control that causes a postback. DIfference here is that when you have AutoPostBack=true, the control can cause the postback itself without any
extra control (to cause the postback). If control does not have
AutoPostBack="true", it is dependant on other controls, to cause the
postback so that events are raised (on the server).

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist
"Matthew Louden" <ma*******@hotmail.com> wrote in message
news:uw**************@TK2MSFTNGP09.phx.gbl...
why need to set autopostback property to be true?? I know autopostback

event
means to send the form to the server automatically.

I tried checkbox, checkbox list, radio button, and radio button list, and they all need to set autopostback property to be true, in order to
make the
event of the control fires.

I know this is the must, but I dont know why. Please advise!

Thanks!


Nov 18 '05 #6
We will have such event, it is called LoadComplete. ;-)

New lifecycle is (not all are events or phases but shows what's happening)

-Page.DeterminePostBackMode
-Page.PreInit
-Page.ApplyControlTheme
-Page.ApplyPersonalization
-Page.Init/Control.Init
-Control.TrackViewState
-Page.InitComplete
-Control.LoadControlState
-Control.LoadViewState
-Page.ProcessPostData (Control.LoadPostData)
-Page.PreLoad
-Load
-Page.ProcessPostData (Control.LoadPostData) 2nd try
-RaiseCallBackEvent
-RaiseChangedEvents
-RaisePostBackEvent
-Page.LoadComplete
-PreRender
-Page.PreRenderComplete
-Page.SavePersonalizationData
-Control.SaveControlState
-Control.SaveViewState
-Render
-Unload
-Dispose

I haven't marked which happen on postback but I guess it is clear from the
context.

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist


"John Saunders" <john.saunders at SurfControl.com> wrote in message
news:uR**************@tk2msftngp13.phx.gbl...
"John Sparrow" <js******@ecclescollege.ac.uk> wrote in message
news:13**************************@posting.google.c om...
Just as an interesting side-point:

If autopostback is false, and a postback is caused by another control
(say a button), events will be generated both for the checkbox and the
button, yes?

But in most code design this will lead to *two* databindings, since
the normal assumption is that only one event in generated per
postback.


That's a very false assumption. There will be one event per control which
wishes to raise an event.
Is there any way to tell which is the *last* control event to be
fired? and do the databind there?

It's almost as if we need a new event handler: AfterOtherEvents()


I agree that we need an event for AfterPostBackEventsButBeforePreRender.
--
John Saunders
John.Saunders at SurfControl.com

Nov 18 '05 #7
"John Saunders" <john.saunders at SurfControl.com> wrote in message news:<uR**************@tk2msftngp13.phx.gbl>...
But in most code design this will lead to *two* databindings, since
the normal assumption is that only one event in generated per
postback.


That's a very false assumption. There will be one event per control which
wishes to raise an event.


But I said "The assumption is that only one event is generated per
postback", ie in that situation two would be generated per postback
(for different controls), not two events per control.

I wonder if there are problems with databinding in the form's
PreRender()??

John
Nov 18 '05 #8
"Teemu Keiski" <jo****@aspalliance.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...
We will have such event, it is called LoadComplete. ;-)

New lifecycle is (not all are events or phases but shows what's happening)


....

Thank you very much for the info. You've made me a happy man!
--
John Saunders
John.Saunders at SurfControl.com
Nov 18 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

22 posts views Thread by Mr Newbie | last post: by
3 posts views Thread by Adrian Parker | last post: by
4 posts views Thread by rn5a | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.