disabling viewstate on datagrid

[sonic]

Hi,
I am experimenting with different viewstate management ideas for large
datagrids, and found a microsoft suggestion to turn it off, and only
store relevant information by manually accessing viewstate. as per some
helpful suggestins in MSDN "Common DataGrid Mistakes"
http://msdn.microsoft.com/library/d...dnaspp/html/aspnet-commondatagridmistakes.asp

they suggest disabling datagrid viewstate and adding selective
information to it i.e. ViewState["editindex"] = this.EditItemIndex etc.

the problem i encountered is, when i set EnableViewState=false, nothing
gets saved there, even though i explicitly save / load viewstate
variables.

Any advice in having it disabled but still using it ?

 

[Eliyahu Goldin]

Where do you specify EnableViewState=false? For the whole page in the <%@
Page...> directive? You should do it only for the grid and other components
you want the ViewState to be off.

Eliyahu

 

[sonic]

disabling it in datagrid as mentioned above

 

[Guest]

I have the same problem. When I disable datagrid viewstate, it skips the
datagrid1__SelectedIndexChanged routine entirely.

George

Where do you specify EnableViewState=false? For the whole page in the <%@
Page...> directive? You should do it only for the grid and other components
you want the ViewState to be off.

Eliyahu

Hi,
I am experimenting with different viewstate management ideas for large
datagrids, and found a microsoft suggestion to turn it off, and only
store relevant information by manually accessing viewstate. as per some
helpful suggestins in MSDN "Common DataGrid Mistakes"
http://msdn.microsoft.com/library/d...dnaspp/html/aspnet-commondatagridmistakes.asp

they suggest disabling datagrid viewstate and adding selective
information to it i.e. ViewState["editindex"] = this.EditItemIndex etc.

the problem i encountered is, when i set EnableViewState=false, nothing
gets saved there, even though i explicitly save / load viewstate
variables.

Any advice in having it disabled but still using it ?

 

[vMike]

I have the same problem. When I disable datagrid viewstate, it skips the
datagrid1__SelectedIndexChanged routine entirely.

George

Where do you specify EnableViewState=false? For the whole page in the <%@
Page...> directive? You should do it only for the grid and other
components
you want the ViewState to be off.

Eliyahu

Hi,
I am experimenting with different viewstate management ideas for large
datagrids, and found a microsoft suggestion to turn it off, and only
store relevant information by manually accessing viewstate. as per some
helpful suggestins in MSDN "Common DataGrid Mistakes"
http://msdn.microsoft.com/library/d...dnaspp/html/aspnet-commondatagridmistakes.asp

they suggest disabling datagrid viewstate and adding selective
information to it i.e. ViewState["editindex"] = this.EditItemIndex etc.

the problem i encountered is, when i set EnableViewState=false, nothing
gets saved there, even though i explicitly save / load viewstate
variables.

Any advice in having it disabled but still using it ?

Try reloading the datagrid on page_init or page_load even during postback.
Mike

 

[Guest]

Thanks vMike. Probably that's the only way to databind the datagrid
everytime. But how do I know what is the new page selection, or the sort
column, if I databind in the Page_Load?

George

I have the same problem. When I disable datagrid viewstate, it skips the
datagrid1__SelectedIndexChanged routine entirely.

George

Where do you specify EnableViewState=false? For the whole page in the <%@
Page...> directive? You should do it only for the grid and other
components
you want the ViewState to be off.

Eliyahu

Hi,
I am experimenting with different viewstate management ideas for large
datagrids, and found a microsoft suggestion to turn it off, and only
store relevant information by manually accessing viewstate. as per some
helpful suggestins in MSDN "Common DataGrid Mistakes"

http://msdn.microsoft.com/library/d...dnaspp/html/aspnet-commondatagridmistakes.asp

they suggest disabling datagrid viewstate and adding selective
information to it i.e. ViewState["editindex"] = this.EditItemIndex etc.

the problem i encountered is, when i set EnableViewState=false, nothing
gets saved there, even though i explicitly save / load viewstate
variables.

Any advice in having it disabled but still using it ?

Try reloading the datagrid on page_init or page_load even during postback.
Mike

 

[vMike]

Thanks vMike. Probably that's the only way to databind the datagrid
everytime. But how do I know what is the new page selection, or the sort
column, if I databind in the Page_Load?

George

I have the same problem. When I disable datagrid viewstate, it skips the
datagrid1__SelectedIndexChanged routine entirely.

George

:

Where do you specify EnableViewState=false? For the whole page in the <%@
Page...> directive? You should do it only for the grid and other
components
you want the ViewState to be off.

Eliyahu

Hi,
I am experimenting with different viewstate management ideas for large
datagrids, and found a microsoft suggestion to turn it off, and only
store relevant information by manually accessing viewstate. as per some
helpful suggestins in MSDN "Common DataGrid Mistakes"

http://msdn.microsoft.com/library/d...dnaspp/html/aspnet-commondatagridmistakes.asp

they suggest disabling datagrid viewstate and adding selective
information to it i.e. ViewState["editindex"] = this.EditItemIndex etc.

the problem i encountered is, when i set EnableViewState=false, nothing
gets saved there, even though i explicitly save / load viewstate
variables.

Any advice in having it disabled but still using it ?

Try reloading the datagrid on page_init or page_load even during postback.
Mike

In general, if the datagrid is user specific you may need to maintain
viewstate or it will go back to its original state. The only other choice is
to maintain some hidden fields or other smaller items in viewstate that will
enable you to recreate the datagrid in the state that the user had at the
time of postback. IMHO viewstate is used to maintain the state of controls
that are specific to one user as opposed to any user.