Dynamic runtime controls, postbacks, Page_Init, Viewstate et al

[Chuck Ritzke]

Hi,

I've searched the newsgroup and other sources to understand how to handle
runtime controls and see I'm not the only one who's confused, but I'm still
not quite sure of the best way to handle from all the various
explanations/answers. I'm attempting the typical scenario...

I create a variable number of controls at runtime based on parameters from a
database.

I understand that I need to re-initialize the controls with the same ID upon
post-back so that the code-behind can see the controls and it's properties.
I also learned that I need to do so in Page_Init instead of Page_Load or the
code-behind won't be able to see the value of the control as
entered/selected by the user. (What's really odd to me when I tried to
initialize in Page_Load, is that somehow, somewhere, the value of those
controls must still exist because, even though I can't get to the value in
code-behind, the value does still get passed back to the browser in the
returning page. I just don't get why I can't get to that value if it's still
there.)

So anyway, I figure I should avoid going back to the database on postback.
So I store the initialization parameters in Viewstate. But of course,
Viewstate isn't available yet in Page_Init. So it seems that I'm forced to
go back to the database to get the initialization parameters (or use Session
or other memory state which I don't think I want to do). But this seems to
defeat almost the whole purpose of Viewstate enabled controls in the
firstplace. If I have to go back to the database anyway, what is the value
in a viewstate enabled runtime control?

Is returning to the database the only/best way to handle these controls, or
am I missing a trick?

Thanks in advance,
Chuck

[Kevin Spencer]

Hopefully, the following article from the .Net SDK should answer all of your
questions. Note that All classes which inherit System.Web.UI.Control
(including Page) follow this same sequence of events. Putting the right code
in the right event handler is the key.

http://msdn.microsoft.com/library/de...nLifecycle.asp
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Chuck Ritzke" <CHUCK AT MYACTUARY DOT COM> wrote in message
news:eS*************@TK2MSFTNGP12.phx.gbl...

Hi,

I've searched the newsgroup and other sources to understand how to handle
runtime controls and see I'm not the only one who's confused, but I'm still not quite sure of the best way to handle from all the various
explanations/answers. I'm attempting the typical scenario...

I create a variable number of controls at runtime based on parameters from a database.

I understand that I need to re-initialize the controls with the same ID upon post-back so that the code-behind can see the controls and it's properties. I also learned that I need to do so in Page_Init instead of Page_Load or the code-behind won't be able to see the value of the control as
entered/selected by the user. (What's really odd to me when I tried to
initialize in Page_Load, is that somehow, somewhere, the value of those
controls must still exist because, even though I can't get to the value in
code-behind, the value does still get passed back to the browser in the
returning page. I just don't get why I can't get to that value if it's still there.)

So anyway, I figure I should avoid going back to the database on postback.
So I store the initialization parameters in Viewstate. But of course,
Viewstate isn't available yet in Page_Init. So it seems that I'm forced to
go back to the database to get the initialization parameters (or use Session or other memory state which I don't think I want to do). But this seems to
defeat almost the whole purpose of Viewstate enabled controls in the
firstplace. If I have to go back to the database anyway, what is the value
in a viewstate enabled runtime control?

Is returning to the database the only/best way to handle these controls, or am I missing a trick?

Thanks in advance,
Chuck

[Chuck Ritzke]

Hi again,

Thanks for the link, but I'm not sure whether it answers my question, unless
the answer is... "you are stuck getting control initialization parameters
from the database on each trip."

The article seems to say...

(1) ViewState and ProcessPostBackData run in between Init and Load events.
(2) There are no LoadViewState or ProcessPostBackData events for me to write
code in so I can't initialize my controls after LoadViewState has occurred,
but before ProcessPostBackData has occurred.
(3) I can't use ViewState during Init event to get my parameters because
ViewState hasn't been loaded.
(4) And I can't wait to re-initialize my controls in Load event because
ProcessPostBackData has already occurred and so I'll not get my posted
values.

Conclusion: I need to find another way to get my control initialization
parameters when the page posts back.

Is that the conclusion I should draw? Or can I somehow force LoadViewState
to happen before I leave Init event?

Thanks again,
Chuck

"Kevin Spencer" <ks******@takempis.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl...

Hopefully, the following article from the .Net SDK should answer all of your questions. Note that All classes which inherit System.Web.UI.Control
(including Page) follow this same sequence of events. Putting the right code in the right event handler is the key.

http://msdn.microsoft.com/library/de...nLifecycle.asp --
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Chuck Ritzke" <CHUCK AT MYACTUARY DOT COM> wrote in message
news:eS*************@TK2MSFTNGP12.phx.gbl...

Hi,

I've searched the newsgroup and other sources to understand how to handle runtime controls and see I'm not the only one who's confused, but I'm still

not quite sure of the best way to handle from all the various
explanations/answers. I'm attempting the typical scenario...

I create a variable number of controls at runtime based on parameters from a

database.

I understand that I need to re-initialize the controls with the same ID

upon

post-back so that the code-behind can see the controls and it's

properties.

I also learned that I need to do so in Page_Init instead of Page_Load or

the

code-behind won't be able to see the value of the control as
entered/selected by the user. (What's really odd to me when I tried to
initialize in Page_Load, is that somehow, somewhere, the value of those
controls must still exist because, even though I can't get to the value

in code-behind, the value does still get passed back to the browser in the
returning page. I just don't get why I can't get to that value if it's

still

there.)

So anyway, I figure I should avoid going back to the database on postback. So I store the initialization parameters in Viewstate. But of course,
Viewstate isn't available yet in Page_Init. So it seems that I'm forced to go back to the database to get the initialization parameters (or use

Session

or other memory state which I don't think I want to do). But this seems to defeat almost the whole purpose of Viewstate enabled controls in the
firstplace. If I have to go back to the database anyway, what is the value in a viewstate enabled runtime control?

Is returning to the database the only/best way to handle these controls,

or

am I missing a trick?

Thanks in advance,
Chuck

[Kevin Spencer]

You can override ANY of those events. Just because the ASPX template that
comes bundled with Visual Studio.Net doesn't have them pre-written for you
doesn't mean they aren't there, or that you can't use them. All you have to
do is use what's available (wisely), and put your code in the proper
sequence.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Chuck Ritzke" <CHUCK AT MYACTUARY DOT COM> wrote in message
news:uM*************@TK2MSFTNGP09.phx.gbl...

Hi again,

Thanks for the link, but I'm not sure whether it answers my question, unless the answer is... "you are stuck getting control initialization parameters
from the database on each trip."

The article seems to say...

(1) ViewState and ProcessPostBackData run in between Init and Load events.
(2) There are no LoadViewState or ProcessPostBackData events for me to write code in so I can't initialize my controls after LoadViewState has occurred, but before ProcessPostBackData has occurred.
(3) I can't use ViewState during Init event to get my parameters because
ViewState hasn't been loaded.
(4) And I can't wait to re-initialize my controls in Load event because
ProcessPostBackData has already occurred and so I'll not get my posted
values.

Conclusion: I need to find another way to get my control initialization
parameters when the page posts back.

Is that the conclusion I should draw? Or can I somehow force LoadViewState
to happen before I leave Init event?

Thanks again,
Chuck

"Kevin Spencer" <ks******@takempis.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl...

Hopefully, the following article from the .Net SDK should answer all of your

questions. Note that All classes which inherit System.Web.UI.Control
(including Page) follow this same sequence of events. Putting the right

code

in the right event handler is the key.

http://msdn.microsoft.com/library/de...nLifecycle.asp

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Chuck Ritzke" <CHUCK AT MYACTUARY DOT COM> wrote in message
news:eS*************@TK2MSFTNGP12.phx.gbl...

Hi,

I've searched the newsgroup and other sources to understand how to handle runtime controls and see I'm not the only one who's confused, but I'm

still

not quite sure of the best way to handle from all the various
explanations/answers. I'm attempting the typical scenario...

I create a variable number of controls at runtime based on parameters from

a

database.

I understand that I need to re-initialize the controls with the same ID

upon

post-back so that the code-behind can see the controls and it's

properties.

I also learned that I need to do so in Page_Init instead of Page_Load

or the

code-behind won't be able to see the value of the control as
entered/selected by the user. (What's really odd to me when I tried to
initialize in Page_Load, is that somehow, somewhere, the value of

those controls must still exist because, even though I can't get to the value in code-behind, the value does still get passed back to the browser in

the returning page. I just don't get why I can't get to that value if it's still

there.)

So anyway, I figure I should avoid going back to the database on

postback. So I store the initialization parameters in Viewstate. But of course,
Viewstate isn't available yet in Page_Init. So it seems that I'm

forced to go back to the database to get the initialization parameters (or use Session

or other memory state which I don't think I want to do). But this

seems to defeat almost the whole purpose of Viewstate enabled controls in the
firstplace. If I have to go back to the database anyway, what is the value in a viewstate enabled runtime control?

Is returning to the database the only/best way to handle these

controls, or

am I missing a trick?

Thanks in advance,
Chuck

[Chuck Ritzke]

Thanks - I had to learn about overriding before I could figure out what you
were getting at, but I finally got it to work. Just in case there is anybody
else out their struggling with the same problem, here is what appears to be
working for me. I added the following routine to the page which allows me to
get at ViewState and initialize my runtime controls before the posted data
is loaded into the controls...

Protected Overrides Sub LoadViewState(ByVal savedState As Object)

Dim dtControlData As System.Data.DataTable

MyBase.LoadViewState(savedState)

'dtControlData contains my runtime control parameters, created and saved
in ViewState the previous time around
dtControlData = ViewState("dtControlData")

'AddSurveyControls re-adds all my runtime controls
AddSurveyControls(dtControlData)

End Sub

Then if I need any new controls that are dependent upon previously posted
entries, I add those in Page_Load or later and add them to my dtControlData
table for the next postback.

Thanks again,
Chuck
"Kevin Spencer" <ks******@takempis.com> wrote in message
news:uf**************@TK2MSFTNGP12.phx.gbl...

You can override ANY of those events. Just because the ASPX template that
comes bundled with Visual Studio.Net doesn't have them pre-written for you
doesn't mean they aren't there, or that you can't use them. All you have to do is use what's available (wisely), and put your code in the proper
sequence.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Chuck Ritzke" <CHUCK AT MYACTUARY DOT COM> wrote in message
news:uM*************@TK2MSFTNGP09.phx.gbl...

Hi again,

Thanks for the link, but I'm not sure whether it answers my question, unless

the answer is... "you are stuck getting control initialization parameters

from the database on each trip."

The article seems to say...

(1) ViewState and ProcessPostBackData run in between Init and Load events. (2) There are no LoadViewState or ProcessPostBackData events for me to

write

code in so I can't initialize my controls after LoadViewState has

occurred,

but before ProcessPostBackData has occurred.
(3) I can't use ViewState during Init event to get my parameters because
ViewState hasn't been loaded.
(4) And I can't wait to re-initialize my controls in Load event because
ProcessPostBackData has already occurred and so I'll not get my posted
values.

Conclusion: I need to find another way to get my control initialization
parameters when the page posts back.

Is that the conclusion I should draw? Or can I somehow force LoadViewState to happen before I leave Init event?

Thanks again,
Chuck

"Kevin Spencer" <ks******@takempis.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl...

Hopefully, the following article from the .Net SDK should answer all of

your

questions. Note that All classes which inherit System.Web.UI.Control
(including Page) follow this same sequence of events. Putting the

right code

in the right event handler is the key.

http://msdn.microsoft.com/library/de...nLifecycle.asp --
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Chuck Ritzke" <CHUCK AT MYACTUARY DOT COM> wrote in message
news:eS*************@TK2MSFTNGP12.phx.gbl...
> Hi,
>
> I've searched the newsgroup and other sources to understand how to

handle

> runtime controls and see I'm not the only one who's confused, but I'm still
> not quite sure of the best way to handle from all the various
> explanations/answers. I'm attempting the typical scenario...
>
> I create a variable number of controls at runtime based on parameters

from

a
> database.
>
> I understand that I need to re-initialize the controls with the same

ID upon
> post-back so that the code-behind can see the controls and it's
properties.
> I also learned that I need to do so in Page_Init instead of

Page_Load or the
> code-behind won't be able to see the value of the control as
> entered/selected by the user. (What's really odd to me when I tried

to > initialize in Page_Load, is that somehow, somewhere, the value of

those > controls must still exist because, even though I can't get to the value

in

> code-behind, the value does still get passed back to the browser in

the > returning page. I just don't get why I can't get to that value if it's still
> there.)
>
> So anyway, I figure I should avoid going back to the database on

postback.

> So I store the initialization parameters in Viewstate. But of course, > Viewstate isn't available yet in Page_Init. So it seems that I'm forced

to

> go back to the database to get the initialization parameters (or use
Session
> or other memory state which I don't think I want to do). But this

seems

to

> defeat almost the whole purpose of Viewstate enabled controls in the
> firstplace. If I have to go back to the database anyway, what is the

value

> in a viewstate enabled runtime control?
>
> Is returning to the database the only/best way to handle these

controls, or
> am I missing a trick?
>
> Thanks in advance,
> Chuck
>
>