What is the meaning of EnableViewState="false" and EnableViewState="true"?
I Know EnableViewState="false" = turn Off the ViewState and also EnableViewState="true" = turn On the ViewState
But What is the difference between EnableViewState="false" and EnableViewState="true" ?
I tried this code:
<form runat="server">
<asp:TextBox ID="TextBox1" EnableViewState="true" runat="server">
</asp:TextBox><asp:Button ID="Button1" runat="server" Text="Button" />
<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
</form>
I am really confused.
When I used EnableViewState="true", I entered some values in textbox and click my button .Now the value is here in the textbox . Its same process when i set EnableViewState="false".
So What happens when EnableViewState="true" and EnableViewState="false" ?
Texbox Doesnt Use Viewstate here is the link to explain all Link Explain
Generally you should use EnableViewState="false" on all controls on the asp.net page. The viewstate of a control is most commonly needed when you want to preserve some visual appearance of the control itself. E.g. if you change the background color of control and you want to persist that across postbacks use EnableViewState="true".
Not all controls are affected by view state. The controls that implement IEventHandler or IDataHandler will not get affected on page postback if view state is disabled.
Textbox is one such control. If you want to see the effect in your code. Try setting the label value at run time on postback like on Click of button and check the results
ViewState is used to persist properties of a control that are set server-side.
So, to take a contrived example, if you do something like the following in Page_Load:
if (!IsPostBack)
{
TextBox1.ForeColor = ...;
}
then the color you set will be preserved across postbacks in ViewState, if it is enabled.
Related
I read Microsoft's article on ASP.Net Page Life Cycle events. It confused on one thing. When Page_PreInit gets called, all the controls' Init method is not yet called. When I setup a test project, I observed a different behavior. In the mark up, I created asp label and button controls and set certain properties such as Text. I put a break point at the beginning of Page_PreInit. When break point got hit, I checked if the controls got created or not by referring to them by their Ids in the Watch window. They all existed and none returned null. Then I checked the Text property and it was what I set in the mark up. So doesn't this contradict what Microsoft says? If this is the case what do Controls' Init method do if they are already initialized? Is there something I miss?
I created asp label and button controls and set certain properties
such as Text. ... Then I checked the Text property and it was what I set
in the mark up.
If you set property value at Design Time, they are in control tree so properties are available in all events.
However, if you add a TextBox and a user clicks on submit, TextBox Text Property only start available at Page_Load event.
The reason is that Page_Load is the place where properties are loaded with information recovered from view state and control state.
Look at this example
<asp:Label runat="server" ID="Label1" Text="Name" />
<asp:TextBox runat="server" ID="TextBox1" />
<asp:PlaceHolder runat="server" ID="PlaceHolder1" />
<asp:Button runat="server" ID="SubmitButton"
Text="Submit" OnClick="SubmitButton_Click" />
After Postback,
Notice that you can only retrieve TextBox value at Page_Load event.
We are using classic ASP.NET 4. There is a GridView that's causing problems because there is no paging and the ViewState is too large. So, disabling the view state via EnableViewState="False" seemed to solve the problem with the viewstate size, but now I can no longer click on rows. The page refreshes, but the call-back corresponding to CommandName="OpenItem" is not firing.
<ItemTemplate>
<asp:ImageButton
ID="Id"
runat="server"
CommandName="OpenItem"
/>
</ItemTemplate>
I tried adding OnClick="ClickHandler" to the ImageButton, but that didn't work either -- the OnClick callback is not firing.
Is there any way, other than adding paging, to have the ViewState disabled and handle clicks on GridView rows?
Thanks.
I'm under the impression that a control in a nested UpdatePanel will cause the top level UpdatePanel to refresh (thus refreshing both UpdatePanels) because any events on that control act as an "implicit" trigger. Is that correct?
I've been trying to wire something like this up-
UserControl
Parent UpdatePanel
"Show" button
ASP:Panel
Dynamically added UserControls, each with UpdatePanels
When the Show button is clicked, the ASP:Panel becomes visible and starts adding UserControls to itself dynamically, based on some back-end logic.
Each of the dynamically added controls (henceforth: UserControls) have their own Atlas-enabled buttons and links, so they have UpdatePanels too. Currently when I click on a link in one of the UserControls, the entire contents of the ASP:Panel disappear, as if it's being re-rendered. All of my dynamically-added controls disappear, and none of their click events are caught in the debugger.
I'm assuming what's happening here is that controls that reside in nested update panels are causing the parent UpdatePanel to post back because they're firing "implicit" triggers. Is there a way for my UserControls to operate autonomously and not mess with the ASP:Panel that contains them?
If not, what strategy should I be pursuing here? If I have to re-render the entire ASP:Panel every time an event happens on one of the (possibly many) UserControls, that means I'll have to recreate the UserControls, which take a bit of effort to create. I'll also have to preserve some kind of view state to recreate them. I'm somewhat new to ASP.NET and that sounds intimidating. I'd rather never refresh the top leve UserControl and ASP:Panel if I can avoid it, and let each of the dynamically-added UserControls fire and handle their own events asynchronously.
EDIT: Instead of adding the controls dynamically, I added them to the markup(not a bad solution). So got rid of the controls disappearing problem, because now the controls are not added dynamically but instead exist in the markup. But still the parent UpdatePanel posting is a big performance hit, because all the UserControls are getting posted instead of one. How do I make only one UserControl postback? Also, I would like to know how to get rid of the problem of controls disappearing if added dynamically?
First off, keep in mind: UpdatePanels do not alter the lifecycle of a page.
All of the Control Tree (including the UpdatePanels) must be reconstructed just as with a Normal Postback Life-cycle.1 2 The UpdatePanels ensure that only a portion of the rendered (HTML) view is returned. Removing all UpdatePanels should result in the same behavior, except with a full postback. For instance, only the HTML representing a nested UpdatePanel (presumably because data changed) might be sent back in the XHR response.
To get "true" AJAX consider Page Methods. Alternatively, DevExpress (and perhaps Telerik and others?) offer their own form of "Callback Panels", which are similar to UpdatePanels, but can bypass parts of the life-cycle (and, as a result often do not support the ViewState model entirely or may introduce their own quirks).
While not understanding the above is the most likely reason for the controls "disappearing", here is my rule: Do Not Let [Nested] UpdatePanels Work "Automatically".
Edge cases with dynamic controls and nested UpdatePanels will be encountered. There might be a nice way to handle this, but I have failed on multiple different attempts.
Instead, for every update panel, run with:
UpdateMode="Conditional"
ChildrenAsTriggers="False"
With the "Conditional" UpdateMode, make sure to manually specify the Trigger control or call panel.Update() (although this hard-wires the Control) as required. Depending on needs ChildrenAsTriggers="True" might work as well. The big thing is that UpdateMode is not "Always" which is the default.
After switching to this approach, I have no problem -- well, almost none -- with nested UpdatePanels.
Happy coding!
1 If the page doesn't render correctly where Partial Rendering (in the ScriptManager) is disabled (e.g. all requests are full postbacks) then there is no reason to expect/believe it will work correctly with UpdatePanels.
2 There are times when it's warranted to "cheat" expensive recomputations in the control tree for controls that will not be re-rendered. However, I would consider these advanced cases that should only be done when performance analysis indicates there is a specific need.
I had a similar issue with a heavy ajax Gridview control, and a HTML page with multiple UpdatePanels, some nested, some not.
It took me over 3 weeks of trial and error, reading, testing, debugging and prototyping to finally resolve all the post backs and partial postbacks.
However I did notice a pattern, which worked for me.
Like the #user above's response, make sure your UpdatePanels are set Conditional and only specificy asp:PostBackTrigger on the final or decisive control that you want the page to do a full postback on. I always use asp:AsyncPostBackTrigger where ever possible.
So for example, if you're using UpdatePanels inside a GridView and you want a popup inside a cell of the gridview's row, then you need to use a nested UpdatePanel.
ie
<asp:TemplateField HeaderText="Actions & Communications">
<ItemTemplate>
<asp:UpdatePanel ID="upAction1" runat="server" UpdateMode="Conditional">
<Triggers>
<asp:AsyncPostBackTrigger ControlID="btnActionOK" />
</Triggers>
<ContentTemplate>
...
...
<ajaxToolkit:ModalPopupExtender ID="ajaxMPE" runat="server"
BackgroundCssClass="modalBackground"
PopupControlID="upAction2"
TargetControlID="btnADDaction">
</ajaxToolkit:ModalPopupExtender>
<asp:UpdatePanel ID="upAction2" runat="server" UpdateMode="Conditional">
<ContentTemplate>
<asp:Panel ID="pnlACTION" runat="server" CssClass="pnlACTION">
<div id="divHDR">
<asp:Label ID="lblActionHdr" runat="server">** header **</asp:Label>
</div>
<div id="divBOD">
<table style="width: 98%; text-align:left">
<tr>
<td colspan="2">
Please enter action item:<br />
<asp:TextBox ID="txtAction" runat="server" ValidationGroup="vgAction" TextMode="MultiLine" Rows="3" Width="98%"></asp:TextBox>
<asp:RequiredFieldValidator ID="rfvAction" runat="server" ControlToValidate="txtAction" ValidationGroup="vgAction"
ErrorMessage="* Required" SetFocusOnError="True"></asp:RequiredFieldValidator></td>
</tr>
<tr>
<td colspan="2">
Select staff assigned to this task:<br />
<asp:DropDownList ID="ddlActionStaff" runat="server" AppendDataBoundItems="true" ValidationGroup="vgAction" />
<asp:RequiredFieldValidator ID="rfvStaff" runat="server" ControlToValidate="ddlActionStaff" InitialValue="0" ValidationGroup="vgAction"
ErrorMessage="* Required" SetFocusOnError="True" Width="98%"></asp:RequiredFieldValidator></td>
</tr>
<tr>
<td colspan="2" style="text-align: center">
<asp:Button ID="btnActionOK" runat="server" Text="OK" OnClick="btnActionOK_Click" ValidationGroup="vgAction" CausesValidation="false" />
<asp:Button ID="btnActionCANCEL" runat="server" Text="CANCEL" OnClick="btnActionCANCEL_Click" ValidationGroup="vgAction" CausesValidation="false" />
</td>
</tr>
</table>
</div>
</asp:Panel>
</ContentTemplate>
</asp:UpdatePanel>
</td>
</tr>
</table>
<asp:SqlDataSource ID="sdsTETactions" runat="server" ConnectionString="<%$ ConnectionStrings:ATCNTV1ConnectionString %>"
...
...
</asp:SqlDataSource>
</ContentTemplate>
</asp:UpdatePanel>
</ItemTemplate>
<ItemStyle HorizontalAlign="Center" />
</asp:TemplateField>
Notice a few things here:
The ModalPopupExtender does not refer to the Ok and Cancel buttons. This is because I want them to trigger a partial postback to the server (code-behind)
The nested UpdatePanel (upAction2) is purely to force a partial postback on that panel only (pnlAction)! Therefore this forces the data validation triggers to work and keep the panel open if the user does not provide data in the requiredfield validators
The main UpdatePanel (upAction1) controls the entire lot and keeps all postbacks held within that panel only and NOT affecting the gridview (not shown entirely).
There is a great article here, which explains it better.
I hope this helps someone
I have a massive viewstate hidden field that is causing my application to be unworkable. I have tried:
EnableViewState="false" on every control
EnableViewState="false" in page directive
Page.EnableViewState = false in Page_Init
<pages enableViewState="false" /> in web.config
The page causing the issue has a single GridView which I want to render once only, so I don't ever need the viewstate.
I examined the hidden field using this tool, and there is apparently hardly any info in it (since I disabled the property in every control probably). For some reason though, the page insists on including a hidden field that is thousands and thousands of lines long.
How can I get rid of this field (or reduce it to a usable size) for good?
Here is an exert from the offending GridView:
<asp:GridView ID="MyGrid" runat="server" AutoGenerateColumns="False"
EnableModelValidation="True" EnableViewState="False"
CssClass="my-report">
<Columns>
<asp:TemplateField>
<HeaderTemplate>
<span title='title' class="abbr">My ID</span>
</HeaderTemplate>
<ItemTemplate>
<%# Eval("my_id") %>
</ItemTemplate>
</asp:TemplateField>
<asp:TemplateField>
<HeaderTemplate>
<span title='title2' class="abbr">Second col heading</span>
</HeaderTemplate>
<ItemTemplate>
<asp:ListView ID="MyListView" runat="server" EnableViewState="False">
<LayoutTemplate>
<ul>
<asp:PlaceHolder runat="server" ID="itemPlaceHolder" EnableViewState="False" />
</ul>
</LayoutTemplate>
<ItemTemplate>
<li><%# Eval("field_2")%></li>
</ItemTemplate>
</asp:ListView>
</ItemTemplate>
</asp:TemplateField>
</Columns>
</asp:GridView>
The hidden field you see on the page is not only for ViewState, it also contains the ControlState. There is no way to disable the control state so you'll need to find a way to live with it. How many items the grid is displaying?
As a last option you may consider compressing generated viewstate field.
Here you have an MSDN article explaining how ControlState works
If your GridView is non-interactive (that is, it doesn't contain any child controls that post back), then you can reduce the size of view state by waiting until the page's Render method is called to bind the grid:
Protected Overrides Sub Render(writer As HtmlTextWriter)
MyGrid.DataSource = ...
MyGrid.DataBind()
MyBase.Render(writer)
End Sub
In case anyone has a similar problem, it was occuring because I had a ListView inside each row of the grid. I replaced the ListView with a Repeater and the viewstate is no longer a problem.
Another option is to use Flesk.ViewState something.
It can put the viewstate on files, compress it, session, etc.
Like the others say, sometimes is inevitable in ASPNET to live with ViewState.
Thats why your best option is to move to MVC :)
So this might be a fairly specific issue but I figured I'd post it since I spent hours struggling with it before I was able to determine the cause.
<asp:GridView ID="gvAttachments" DataKeyNames="UploadedID" AutoGenerateColumns="false" OnSelectedIndexChanged="gvAttachments_SelectedIndexChanged" runat="server">
<EmptyDataTemplate>There are no attachments associated to this email template.</EmptyDataTemplate>
<Columns>
<asp:TemplateField ItemStyle-Width="100%">
<ItemTemplate>
<asp:LinkButton CommandName="Select" runat="server"><img src="/images/icons/trashcan.png" style="border: none;" /></asp:LinkButton>
</ItemTemplate>
</asp:TemplateField>
</Columns>
</asp:GridView>
In the ItemTemplate of the TemplateField of the GridView I have a LinkButton with an image inside of it. Normally I do this when I have an image with some text next to it but this time, for whatever reason, I just have the image. This causes the UpdatePanel to always do a full postback.
Instead of changing the markup, you can goto web.config and specify ClientIDMode="Auto" in the pages tag.
Reason why UpdatePanel behaving like this is because the ClientIDMode is getting generated will be too long for UpdatePanel to register. So the ClientID got truncated in middle and such control will be treated like unregistered Control.
For more information read the following:
http://msdn.microsoft.com/en-us/library/system.web.ui.control.clientidmode.aspx
Change the LinkButton to be an ImageButton and the problem is solved.
<asp:ImageButton ImageUrl="/images/icons/trashcan.png" Style="border: none;" CommandName="Select" runat="server" />
Above solutions also work, But There is one more thing to check. Check form tag for your page. If id attribute is missing, you will get same issue.
If you form tag is as given below (without id), you will get issue:
<form runat="server">
<!-- your page markup -->
</form>
Please add id, as given below:
<form id="form1" runat="server">
<!-- your page markup -->
</form>
You will not need to update ClientIDMode in web.config or page or control.
You will not need to change your linkbutton in markup.
You will not need to register control for asynch postback from code behind.