EnableViewState

[Just D.]

Does anybody know any good solution to avoid this setting to be enabled? I
guess Microsoft doesn't care of the Internet connection of the potential
client working with asp.net. This EnableViewState setting is TRUE by default
and it causes the whole page to be serialized and sent to the server side
and then downloaded back to the client machine dramatically increasing the
whole traffic. Example? Ok. A simple page (or frame) with this setting
equals FALSE weights about 200 Kbytes, it has several controls, one
DataGrid, etc. Same page with this EnableViewState=TRUE takes 6 Mbytes. I'm
just wondering if we really need to upload the whole stuff to the server and
then to download it to the client side or it can be decreased using some
tricks?

Although if we disable that then some or all of the controls lose the data
entered by the user, including the selected row on the datagrid, text boxes,
etc. But is it really a very good solution to follow this directions or we
could do anything more efficient?

Just D.

 

[Juan T. Llibre]

re:

Does anybody know any good solution to avoid this setting to be enabled?

Have you tried setting the attribute to "false" ?

<%@ Page Language="VB" EnableViewState="false"%>

That would turn it off for a single page.

To turn it off for all the pages in an application, use :

<pages enableViewState = "false">

in Web.config.

re:

I guess Microsoft doesn't care of the Internet connection of the potential client
working with asp.net.

That's a cheap shot.
You should get better informed before throwing a cheap shot like that one.

Ignoring something is no excuse for cheap shots.

 

[Just D.]

You know, first of all you should read my message twice before writing the
advice like this. Yes, I tried to disable this option and I wrote about the
results this turn off leads to. So what? As people say in some countries you
shut in a milk, Mr. MVP.

 

[Juan T. Llibre]

re:

Yes, I tried to disable this option and I wrote about the results this turn off leads to

I can barely imagine the form control's values you're trying to save
in viewstate if it takes 6MB worth of viewstate to persist their state.

What leads you to believe that a "by-design" feature, like viewstate,
should work both when it's enabled and when it's not ?

Either you understand that viewstate works when it's enabled
and it doesn't work when it's disabled, or you'd better find yourself
another life goal than becoming an ASP.NET programmer.

You should know that control values' state can be persisted
in cookies and in the querystring, besides viewstate.

But, if it takes 6MB to save your form's values' state in viewstate,
I can tell you that neither cookies nor the querystring will be
able to hold those values' state.

re:

Mr. MVP

I'll add *that* cheap shot to your earlier cheap shot :

I guess Microsoft doesn't care

They sure paint your attitude to a " T ".

 

[Just D.]

Juan, listen, it's not a good place to argue about obvious things, if you
really want let's go to email to discuss that in detail, I can give you an
example of such a frame, if not, then we'll go different ways and please do
not lose your time answering. Maybe in email you become not so aggressive
and really can give a good advice if you know what you're talking about,
instead of all this flame.

I see what I see, the same frame with only one property enabled or disabled
shows in the IE source code 200 kbytes and 6 mbytes. And this is not a
question for me. One more hint, I'm not a boy and write programs beginning
from 1979 to realize what's true. Yes, the serialization of the form data is
terrible, especially if we use a lot of different components like
Infragistics controls, and we all know that to reject it in so aggressive
form like yours. I'm also sure that if the EnableViewState=TRUE then the
form will have and serialize all hidden components, even those that never
should be shown on the client side and that's why the frame source code size
is terrible, if it's FALSE then the downloaded frame has only the components
that should be shown on the client side, all other data is deleted, that
what I'm seeing, just a couple buttons, table, a very simple HTML code.

Maybe you're still remembering that the initial question was how to avoid
the situation like that, maybe using java scripts to store some data into
temporary controls, URL or whatever and disabling the ViewState for the
whole datagrid. There are a lot of ways and if you're a programmer you
should know about that. So don't be one-sided and try to think deeper.

Regarding cookies, that's good but how the cookies can help you to
understand which row on the datagrid was selected to retrieve the data on
the server side?

Another limitation - security, HIPAA limitation. This info should be stored
in memory only, all disk caching, cokies or whatever are disabled. The
browser has a serious bug with the caching and it shows the obsolete data
even if it's updated, to avoid this bug I have to use another methods. The
cache disabling works in most cases but not always bringing us a lot of
surprises, if you work with images, it never works correctly, etc. The
problem is too complex to discribe it in a few words and I'm sure that a lot
of people are fighting with the same problems on their own. My Internet
connection allows me to work extremely fast but if the app doesn't work on a
slower connection then .NET loses much more that was expected.

It's pretty strange that nobody joined this discussion with a more positive
behavior.

Btw, are you working for Micro$oft? The style of your answers...

Regards.

 

[Juan T. Llibre]

re:

Btw, are you working for Micro$oft?

That comment explains a lot about your attitude,
like your two previous cheapshots do, too.

Like I said, you have 3 choices to persist control state:

1. viewstate
2. cookies
3. querystring

Take your pick.

 

[vMike]

Does anybody know any good solution to avoid this setting to be enabled? I
guess Microsoft doesn't care of the Internet connection of the potential
client working with asp.net. This EnableViewState setting is TRUE by
default

In general, you can enableviewstate on a control by control basis (the pages
enableviewstate must be set for true though or all the controls on the page
will be false regardless of their individual setting). You can then turn it
off for any control which the user cannot change state. Usually you must
leave it on for drop down boxes. You will find, at first that with viewstate
false you can't get values for controls such as datagrids etc., but if you
rebind them in the page_init or page_load you can access those controls just
as though viewstate was enabled. This adds server overhead but that is the
tradeoff for lowering viewstate. Taking it a step further you can place your
own little pieces of info in viewstate for the page when you need to
retrieve it on postback. If you do that you need to look into

Protected Overrides Sub LoadViewState(savedState As Object)
If Not (savedState Is Nothing) Then
MyBase.LoadViewState(savedState)
End If
End Sub

and

Protected Overrides Function SaveViewState() As Object
ViewState("MyInfo1") = "1" 'for example
Return MyBase.SaveViewState()
End Function


Keep in mind also that when you are retrieving viewstate info you must check
for its existence first as in

if not ViewState("MyInfo1") is nothing then
SomeInfo1 = ViewState("MyInfo1")

else
do this
end if


I was able to reduce viewstate from 18K to 1K. It will take a bit of time to
rewrite some of you code, but it can be done.

Hope this answers you question.

Mike

 

[Just D.]

Mike,

Thank you for your answer. That's very interesting especially the part when
you wrote that you were able to decrease this state from 18 to 1 kbyte.
Awesome! I have to review this approach in detail for my pages.

In general, you can enableviewstate on a control by control basis (the
pages enableviewstate must be set for true though or all the controls on
the page will be false regardless of their individual setting). You can
then turn it off for any control which the user cannot change state.
Usually you must

Yes, I know about that and was playing with that as well. I found one
article where the author wrote about that and why it should not be used in
most cases where we're using PostBack.

I noticed one interesting thing, maybe it's documented somewhere, but I've
never seen any info about that yet and I can't consider if this is a bug or
feature. By default this EnableViewState=TRUE even if the tag is not added
to the page or control. When I change this state to FALSE using the VS2003
IDE the tag appears to the control or to the page with the value =FALSE.
That's fine. I can switch to HTML mode to check that. When I want to enable
this state back I switch to the design mode and click one more time changing
the false status to true, what's happening then? I switch again to HTML mode
and see that the tag remains in the page header like EnableViewState=TRUE
and disappears to the controls even if it was defined before as
EnableViewState=FALSE. Mistery or some deeper idea? Maybe.

leave it on for drop down boxes. You will find, at first that with
viewstate false you can't get values for controls such as datagrids etc.,
but if you
Exactly!

rebind them in the page_init or page_load you can access those controls
just

Yes, as a rule I bind the datagrids only once on_load, and I always use
(!IsPostBack) before I bind the data. In some rare cases I have to rebind
the data when something changes on the page like the User's selection and I
have to renew the datagrid.

I also noticed that in some cases if a TextBox was having the info before
PostBack it can have the same info even if the EnableViewState for this
control is disabled. But it doesn't work for radiobuttons, checkbuttons,
etc. It must be enabled anyway.

as though viewstate was enabled. This adds server overhead but that is the
tradeoff for lowering viewstate. Taking it a step further you can place
your own little pieces of info in viewstate for the page when you need to
retrieve it on postback. If you do that you need to look into

Sometimes I use the hidden controls like labels to store some info as text.
Not very often although because it's not very efficient, but convenient.

I was able to reduce viewstate from 18K to 1K. It will take a bit of time
to rewrite some of you code, but it can be done.

That's very interesting!

Hope this answers you question.

Yes, you gave me absolutely new direction to move ahead, thanks a lot!

Mike

Just D.