I am trying to wrap my head around the control infrastructure to understand which ones ASP.NET maintains view state for.
There are these regular HTML controls ex:
<input type="radio" checked="checked"/> -> I understand these do not have viewstate
Then there are HTML controls with runat=”server”
<input type="radio" checked="checked" runat="server"/> -> Does the viewstate get maintained between postbacks?
Then there are ASP.NET controls
<asp:TextBox id="txtMyText" runat="server"/> -> I understand these do have viewstate
We have a few custom controls that inherit HtmlTextBox
<myPrefix:myTextBox id="txtMyText" runat="server"/> -> Is this the same as type 2 above?
Is it safe to assume that any control with
runat="server" tag will have viewstate maintained?
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
There are 3 types of controls, the standard HTML elements like , HTML server controls which have the runat=server tag added, and full web controls. Only the web controls have viewstate maintained.
When we were having problems with viewstate I started using the Viewstate helper software from Binary Fortress http://www.binaryfortress.com/aspnet-viewstate-helper/
It gives you a real insight into what’s going on – as well as helping with viewstate related performance issues you can decode the viewstate with one click and see what is actually in there – so you get to understand what controls are using viewstate and which aren’t, and exactly what they are storing in there.
Also, something nobody else has mentioned is ControlState. This came along with ASP.NET 2 and the theory is that the important stuff that is necesssary for a control to function goes in the control state, and the data etc in the viewstate, so you can switch off the viewstate and bind the data to your control on every postback and the control still basically works using controlstate. I say “theory” because in practice the implementation seems patchy. When you look into the dropdownlist code using reflector for example this isn’t properly implemented. This may have changed with later releases of the framework, I’m not sure. Lots of info on controlstate out there if you search for it, I just thought I’d mention it.
afaik no, that HTML controls are not designed to maintain anything in the viewstate, if you care about it, take the webcontrols.
Anything you put on your page’s view and add the runat=”server” will have the viewstate maintained.