I have a button that adds an already defined usercontrol programtically. I am rebuilding each control on Postback and they show up fine. If I put text in the textbox it shows up fine, however my images are losing their url. Any idea why or how I can fix this?
I tried adding AJAX updatepanel to see if that would help, but it does not.
To further explain - I have a button that after clicks set the url of the image - I also put this value in the textbox just to see if the same thing happens - after postback, my textbox still has the value, but the image does not - and all of my other ASP.Net images lose their image and they are defined right on the controls (ie: ImageUrl)
--- update
OK, I have found some more insight to my issue - some solutions but still one problem remains.
The reason the images were loosing their url is because they were and not ASP.Net images - ASP.Net remembers the values when they are recreated on postback - however the Main image that im changing via javascript looses its value - I'm very certain this is because of using javascript to change it, on post back it reverts back to the previous value... so for a solution I will try to stuff it in a hidden value, then use that value on postback to define the ImageUrl of the image...
You are correct <img> is an html control, while <asp:Image> is a server control. As long as server controls have viewstate enabled they will keep their values during postbacks.
You are correct that changing an image's URL via JavaScript will not get it returned during the postback as this is not a form value. Therefore, it will be lost forever if you do not save it into a form field, such as the hidden field that you suggested.
Image is not form field. That is why it's value is never posted back to server.
The reason your asp:Image controls retain value during postback is because they are stored in viewstate (which is stored in hidden field). When you click button this viewstate is posted back to server, and asp.net sets the ImageUrl property of image control from viewstate in early events of page lifecycle.
In short the server side form controls values are available after postback. Same way if you have normal html form fields (https://www.w3schools.com/html/html_form_elements.asp), you will get it's value using Request.Form collection.
You are setting your Image's src using javascript (and which is obviously not in original viewstate), that is why you are not getting it's value in postback. You should use Hidden Field to set value using javascript, which can be available after postback.
Related
I was reading about the difference between Disabled vs Read only and I learned that with a disabled field the data is not send back on postback.
However I have a webforms page with a textbox like below:
<asp:TextBox runat="server" ID="vPlantNameTB" Text="" Enabled="false"></asp:TextBox>
On page load I set the value of vPlantNameTB to some value. (instead of blank).
Since I have this TextBox disabled. I expect the value of the TextBox to be blank on post-back. But that is not the case...
I am able to get the value I set it to on page load during post-post back.
Is this behavior normal for web-forms?
In short:
yes, because the value is coming from your viewstate, not the form.
For a slightly more involved answer...
The form data that gets submitted (accessible through Request.Form) will be missing for vPlantNameTB as it is disabled and therefore not sent by the browser to the server.
Also included in the form data sent to the server is a hidden input (generated by the .Net engine) called __VIEWSTATE and it's value is a base64-encoded string that represents the current state of the page.
The page state automatically serialized out to the rendered web page and automatically deserialized when the form is posted (the deserialization process also handles re-association with your page controls which is why vPlantNameTB has a value again in your postback handler).
Scott Mitchell has a decent article about ViewState on MSDN which describes the process quite well.
I've got a number of RadGrids in various pages but on one of them, a particularly big one, now when the user changes the Page Size via the Pager text field it doesn't keep that: when the grid finishes updating it's reset the Page Size back to whatever it was. If I change the PagerStyle.Mode so there's a dropdown shown instead of a text field then they can change it just fine. I can change it back & forth between NextPrevNumericAndAdvanced and NextPrevAndNumeric, and consistently it works with a dropdown (NextPrevAndNumeric) but not with a text field (NextPrevNumericAndAdvanced). If I modify the Page Size with the pager shown as a dropdown, then change the aspx to use a text field, then it locks the Page Size at whatever I selected in the dropdown.
What could it be that is causing this?
Turns out the if (!Page.IsPostBack) ... had been removed from Page_Load, so on every postback it was resetting things. Putting this back resolved the problem.
I am dynamically loading user controls to switch between views in my project. I am aware that I need to reload my user control on every postback. The odd thing is my viewstate for the control is maintained even though the control is gone? I confirm that the panel I loaded it into is empty and then I check the view state and my value is there.
What's stranger is that if I load a different control, it can see the viewstate from the previous control? I checked and my page cannot see viewstate from my dynamically loaded control and visa versa. This makes me think the user control is treated as its own page. The confusing part is why the second view I load can see values from the first and why the values are there even though I the control has disappeared?
I also find this section of the code to be useless. Why is it removing the control? The panel is always empty (the code is from Telerik):
string controlId = LatestLoadedControlName.Split('.')[0];
Control previousControl = pnlControlPlaceholder.FindControl(controlId);
if (!Object.Equals(previousControl, null))
{
this.pnlControlPlaceholder.Controls.Remove(previousControl);
}
I looked at several posts and most say that viewstate is lost on every postback, although this is not the case for me. Perhaps because I'm using update panels. Although if an intial request handles an event and then reloads the same control again, the viewstate is lost. It only seems to preserve the viewstate on the very next postback.
Can anyone explain this odd behavior of sharing viewstate between user controls or why it is there even though the control is lost?
Apparently you can read viewstate between pages in two scenarios... Cross page postback and when using Server.Transfer. I believe the cross page postback scenario would explain what I am seeing.
I'm filling some labels using jQuery AJAX and it's working properly (i'm getting the values through webservices). But after that, i'm firing and Button click to get that values but in debugging the labels are empty.
I think it's because the values are losing in PostBack.
Is there anyway to keep those labels values on Postback?
Since the labels are just text in the HTML, there is no data being sent back in the Post that tells ASP.NET that the labels have changed.
You may need to include a Hidden field to track the text of the labels.
That being said (and since you are already using jQuery), I would recommend using a call-back rather than a post-back for this particular scenario.
I am using AjaxToolkit:ReorderList Control in an asp.net page(C#) and changing value of a viewstate[""] on OnItemReorder event, when I click on any button on the same page the value of viewState is not founded.
Please provide me appropriate solutions.
Thanks...
As far as I understand it, the OnItemReorder event happens in something other than a regular postback. Thus, the page is not re-rendered, and consequently the changed ViewState doesn't get sent back to the client. As a result, when you do a real postback, you send back the original ViewState from before you made the change.
I got around this by storing the data I was trying to sort in a session variable rather than ViewState, but I'm not entirely happy with that.