ASP.NET textbox losing value after postback when value is changed client-side via javascript.

Question

I am setting the value of a textbox via javascript client-side. When I refresh the page the value is lost.

The textbox is not disabled or set to read-only.

I have read suggestions to put the value in a hidden field, I'd prefer not to do this. It seems like a hack.

The textbox is in a user control as such:

<div id="Row" class="RaidRow" runat="server">
    <asp:Button ID="RaidRowButton" runat="server" CssClass="RaidRowButton" OnClick="RaidRowButton_Click" />
    <asp:TextBox ID="CharacterNameTextBox" runat="server" CssClass="RaidRowControl SlotTextBox" MaxLength="12" />
    <asp:Label ID="ClassNameLabel" runat="server" CssClass="RaidRowControl ClassLabel" />
</div>

This control is on the .aspx page.

When the user double-clicks the textbox, presses enter while the textbox has focus, or changes the text, the following javascript function is called:

function VerifyCharacter(slotNumber, event)
{
    var enterWasPressed = false;

    if (event && event.which == 13)
    {
     enterWasPressed = true;
    }
    else if (window.event && window.event.keyCode == 13)
    {
     enterWasPressed = true;
    }

    if (event == null || enterWasPressed)
    {
     var realmName = 'Lightninghoof';

     var characterNameTextBox = GetCharacterNameTextBox(slotNumber);
     characterNameTextBox.style.color = '#CCCCCC';

     var classLabel = GetClassNameLabel(slotNumber);
     classLabel.style.color = '#CCCCCC';
     classLabel.innerHTML = 'Unknown';

     WoW_Stats.CharacterInformation.GetCharacterInformation(realmName, characterNameTextBox.value, slotNumber, GetCharacterInformation_Success, GetCharacterInformation_Failed);
    }
}

Once the web-service call is complete, the following javascript function is called:

function GetCharacterInformation_Success(characterInformationResult)
{
    var characterInfo = Sys.Serialization.JavaScriptSerializer.deserialize(characterInformationResult, true);

    var classLabel = GetClassNameLabel(characterInfo.SlotNumber);
    classLabel.style.color = characterInfo.ClassColor;
    classLabel.innerHTML = characterInfo.ClassName;

    var characterNameTextBox = GetCharacterNameTextBox(characterInfo.SlotNumber);
    characterNameTextBox.style.color = characterInfo.ClassColor;
}

The only problem is that when I refresh the page, the text in the CharacterNameTextBox and ClassNameLabel, which were set client-side via javascript, are lost.

How can I make sure the controls retain their value between postbacks?

Answer 1

Storing values in a hidden field is no more of a hack than .NET Web Forms itself is. Much of the application data is passed/stored in the hidden __VIEWSTATE field.

That being said, could you clarify what is going on? Are you setting the value on page load, or in reaction to some user action? Could you provide some of your code so that we can have a clearer picture of what you are doing?

EDIT

Are you explicitly setting the value of either of the textbox or the label in your page load/postback codebehind? That would override any values being set by the client script. I can't think of any other reason why the values would not persist. If you're really desperate, you could send the information back to the server via an AJAX call at the end of your javascript function, so that you have it in server memory somewhere.

Answer 2

when do you set the value? You could set the value onload of the page in javascript as long as you are using the clientId of the textbox.

Answer 3

The only problem is that when I refresh the page, the text in the CharacterNameTextBox and ClassNameLabel, which were set client-side via javascript, are lost.

Since you are setting the value client-side I would suggest using cookies to store that data and checking for that cookie in your client-side, since ViewState will not help here if you are just setting the value client-side regardless of what CodeBehind would set it to be.

Answer 4

The problem could be one of two things. The refresh could clear then field. Also, if you are posting back, do you set the value of the text box on the page load (or unload) event?

Answer 5

Refreshing the page (pressing F5) is different than a postback. I don't believe the value in your text box is going to be posted back to the server on a refresh. The value in the text box will get posted back to the server on a postback though (as long as the ReadOnly attribute of the TextBox is not set to true, but that's a different story).

Answer 6

On your In the page preinit event, try accessing the value like this:

Request["CharacterNameTextBox"]

I was running into the same issue (a value set via javascript would never post back, but a typed in value would) and a co-worker suggested it. Dead on, works like a charm.

Jeff

Answer 7

You have to remember, KISS.

Just think of your existing fields as presentational in nature and add hidden input fields with a runat="server" attribute and set those with JavaScript in your same client-side event.

Those are your real values you want in your code-behind methods and you'll be able to grab those no problem. Since the textbox object is a .NET abstraction, I would suggest when doing heaving client-side work using HTML inputs that are run at the server. It seems to save me a headache when I'm knee-deep in web forms BS.

I think there are a lot of solutions here, but I'm all for breaking the wrist and walking away if I can.

Answer 8

I have a similar problem. I'm using the Windows Forms WebBrowser object and accessing the DOM using the WebBrowser's Document property. I'm setting the values for various elements in an ASP.Net website that I don't have any control over - but when an element triggers a postback and the page is returned the values entered are all reset to defaults.

When typing the values in directly, all of this functionality works okay.

Is the setting of the VIEWSTATE ignored when setting element values using the DOM? Any one any ideas what's going on?

Thought I would add: the DOM manipulation occurs once the page is fully loaded otherwise it's just not available.