Use Viewstate info instead of nested FindControl?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

John Kotuby - 11 Dec 2007 11:37 GMT

Hi all,
After more than a year programming with ASP.NET 2.0 and VB I am still
finding it difficult to leave some habits from classic ASP behind. this is
particularly true with cross-page posting. My site uses Master pages and
user controls. On an Advanced Search page I have numerous entry boxes and
listboxes (keywords, categories, etc.) which are primarily standard HTML. I
post this page to a different page which lists results and additional info
using a repeater control.

I have added a new search criterion in the form of a DropDownList control,
specifically for the ease of programming on the server-side -- or so I
thought.

To retrieve the SelectedValue I find it necessary to use nested FindControl
methods to get to the control. An example follows:

varOwner = "" 'populate the variable in case the following code fails
Dim pp_lstOwner As DropDownList
Dim pp_placeholder As ContentPlaceHolder
Dim pp_SearchEdit As UserControl

pp_placeholder = CType(Page.PreviousPage.Master.FindControl("Content1"),
ContentPlaceHolder)
If Not pp_placeholder Is Nothing Then
pp_SearchEdit = CType(pp_placeholder.FindControl("SearchEdit1"),
UserControl)
If Not pp_SearchEdit Is Nothing Then
pp_lstOwner = CType(pp_SearchEdit.FindControl("lstOwner"), DropDownList)
If Not pp_lstOwner Is Nothing Then
varOwner = pp_lstOwner.SelectedValue
End If
End If
End If

Not the most elegant code but it seems to work. All the native HTML controls
I use can be accessed simply.

varKeyWord1 = Request("txtKeyWord1")

Which is much cleaner more easily understood code.

I have not utilized ViewState at all in my code to retrieve values. In fact
I see many examples (in books) of code "turning off" ViewState to reduce the
size of the transmitted pages. I have been reticent to "turn off" any
ViewState being concerned about possible adverse consequences... the code
works so why break it?

My question is can I use ViewState of the DropDownList to retrieve the
SelectedValue more easily than the nested mess above?

And I still need to learn when I can safely turn off ViewState for Server
controls without breaking functionality. BTW...the DropDown list is
populated by over 3000 values.

Thanks for any suggestions.

Reply to this Message

John Kotuby - 11 Dec 2007 17:19 GMT

Hi all again,

After doing some additional research regarding ViewState, it seems that the
SelectedIndex and SelectedValue of a List type control might not be
transported properly

If I include a handler for the SelectedIndexChanged of the DropDownList in
the Requesting page, that handler will be fired before the page is
cross-page posted allowing me to populate a variable with the new
SelectedValue of the DDL. If I create a Hidden form field whose value
matches the variable contents then I can simply reference the contents of
that hidden field as in:

varOwner = Request("HtxtOwner")

I must still do some more reading on viewstate to convince myself it is
worth using in any context.

During my research I also came across the concept of ControlState. However,
the examples I have seen so far show the LoadControlState and
SaveControlState methods used in conjunction with
Page.RegisterRequiresControlState and the RegisterRequireControlState
methods but only in the context of "Custom" server controls, it would
appear.

I might have to become a real programmer to fathom the depths of these
concepts, and I thought that Assembly language and Fortran were abstract!

> Hi all,
> After more than a year programming with ASP.NET 2.0 and VB I am still
[quoted text clipped - 51 lines]
>
> Thanks for any suggestions.

Reply to this Message

Scott Roberts - 11 Dec 2007 18:20 GMT

>> After more than a year programming with ASP.NET 2.0 and VB I am still
>> finding it difficult to leave some habits from classic ASP behind. this
[quoted text clipped - 3 lines]
>> HTML. I post this page to a different page which lists results and
>> additional info using a repeater control.

"Cross-page posting" is frowned-upon and you'll find lots of "simple" things
that "don't work" when you go down that path. May I suggest that you forget
cross-page posting and just have your search page generate the results,
store them in the user's session, then redirect to the "results" page. The
results page will obtain the results from the session and display them.

I think you'll find that working within the "standard" page-lifecycle avoids
many of the problems you are encountering.

Reply to this Message

John Kotuby - 12 Dec 2007 00:56 GMT

Sounds like a very good suggestion Scott.
I can see how a lot of problems would be avoided.
I will do that for any new work ahead. For now I must deal with some
extensive existing work that at the moment does not allow the time for a
nearly complete re-write.

Many thanks for that point of view...

Is there any mechanism other than Session variables that I might use to
transfer the data in conjunction with a Response.Redirect?

Actually is Response.Redirect the accepted and standard way to move from
page to page after using standard postback? I would think that method would
be clearly stated in almost all Beginning ASP.NET books or tutorials. Most
examples show how server controls are used in a simple postback and don't
even bother to cover the topic of moving "state" data (or any other data)
between pages.

Can someone point me to a tutorial spcifically covering those fundamentals?
I have reviewed a complete chapter on Maintaining State in a Wrox
Professional ASP.NET book and realize they spend more time on mind deadening
theory than actual practice.

>>> After more than a year programming with ASP.NET 2.0 and VB I am still
>>> finding it difficult to leave some habits from classic ASP behind. this
[quoted text clipped - 13 lines]
> I think you'll find that working within the "standard" page-lifecycle
> avoids many of the problems you are encountering.

Reply to this Message

Scott Roberts - 12 Dec 2007 05:42 GMT

> Is there any mechanism other than Session variables that I might use to
> transfer the data in conjunction with a Response.Redirect?

Well, there is the Application cache and static variables, but if you use
those you'll need to implement some mechanism for keeping each user's data
separate as well as "cleaning up" after yourself. If you're using a
cross-page postback (meaning the search form actually posts to the results
form instead of using a Response.Redirect in the code-behind of the search
form) then you can use POST data - see below.

> Actually is Response.Redirect the accepted and standard way to move from
> page to page after using standard postback? I would think that method
> would be clearly stated in almost all Beginning ASP.NET books or
> tutorials. Most examples show how server controls are used in a simple
> postback and don't even bother to cover the topic of moving "state" data
> (or any other data) between pages.

Response.Redirect, as far as I know, is the accepted standard. The reason
you don't see anything about moving "state" between pages is that it's not
standard and it's not "easy".

When working with cross-page postbacks you pretty much get the POST data and
nothing else. And you have to use Request.Form or Request.Params to get at
those, I believe. If the viewstate *is* posted to the new page (it is just a
hidden form field, after all) I think you'll have to decode it and parse it
yourself. I've never gone down that path, so I'm probably not the best guy
to be giving advice here. Just trying to give you some things to look into.
Try setting a breakpoint in the destination page and checking
"Request.Params" to see what you're given. Maybe you'll find enough in there
to solve your problem.

Reply to this Message

John Kotuby - 12 Dec 2007 16:34 GMT

Scott,
Thank you so much for taking the time to anwer my questions. Now I undestand
that the Viewstate is used during a simple post-back which makes accessing
the contents of Server controls very easy, even if they are nested several
levels deep in User controls. I guess it also allows user-made changes to
the page to persist if the page is re-displayed.

I understand that most of the control values can be accessed at the
Page_Load event. I have heard that the results of other server-side events
(such as the SelectedIndexChanged ) must be accessed later on in the page
life-cycle like at the Page_PreRender stage.

Your insight is very useful to me.

Wishing you the best...

>> Is there any mechanism other than Session variables that I might use to
>> transfer the data in conjunction with a Response.Redirect?
[quoted text clipped - 26 lines]
> checking "Request.Params" to see what you're given. Maybe you'll find
> enough in there to solve your problem.

Reply to this Message

Use Viewstate info instead of nested FindControl?

Free Magazines