Juri Strumpflohner
Juri Strumpflohner Juri is a full stack developer and tech lead with a special passion for the web and frontend development. He creates online videos for Egghead.io, writes articles on his blog and for tech magazines, speaks at conferences and holds training workshops. Juri is also a recognized Google Developer Expert in Web Technologies

Changed values of readonly and disabled fields not accessible after postback

3 min read

I don't know whether you noticed this problem already. ASP.net doesn't seem to handle the viewstate of disabled and readonly controls on the UI (i.e. textboxes etc...). I had the following feature: there where 4 text-fields, one after the other. The first one shouldn't be edited directly by the user wherefore it has been set to readonly. The other fields are usually automatically filled out according to some other information. Furthermore the feature stated that if the user changes one of the autocompleted fields, the value of the first (readonly) text-field should be emptied. To enhance the user experience everything should happen without a post-back. So due to the easiness of this task, I added a client-side JavaScript change event handler on the 3 text-fields where any change would empty the first field. In this way no postback has to be done which improves the performance and user experience. Everything seemed to work out fine, the first field was cleared correctly. But then, after the postback, the value was again there. After trying around a bit, I recognized that the viewstate isn't handled for readonly and disabled fields (enabling the field caused everything to work fine). To some degree this is reasoning is also understandable. ASP.net is a server-side technology (at least prior to the introduction of ASP.net Ajax) wherefore client-side changes are not taken into consideration. So since readonly and disabled fields aren't supposed to be changeable between postbacks their viewstate doesn't have to be handled. But as you can see there may be cases where this isn't true.
What you have to do so is to create some workaround. I researched a bit on the web and found some solutions where developers worked with hidden fields. I don't like that however, my solution was to handle this via JavaScript by "simulating" a readonly textbox. There are basically two different approaches:
  1. Fast solution
    The fastest solution is for sure to simulate a readonly textbox. That can be achieved by creating a CSS class that mimics the style of a readonly text field. Moreover to avoid that the user is able to change the content of the text-field (which is the intended behaviour of a readonly field), you return "false" on the onkeypress, onkeyup and onkeydown events. The effect of this solution is that you have a normal textbox wherefore its viewstate will also be treated normally.
    Note: You should take care the the user is able to navigate over the field by using the tab-key. That can either be achieved by setting the tabindex to "-1" s.t. the field never receives the focus or you don't return "false" on the event handlers in case that the "tab"-key was pressed.
    Example:

    <asp:TextBox ID="txbWorkOfficeCompanyCode" runat="server" CssClass="m text readonly" onkeydown="return false;" onkeypress="return false;" onkeyup="return false;">
    </asp:TextBox>

  2. Cleaner solution
    The cleaner solution is to exploit the ASP.net Ajax functionalities and create a TextBoxExtender which includes the functionalities mentioned in point 1. This solution is cleaner since you could add the extender on a text-field without directly modifying the textbox itself. Moreover it facilitates reusability which is a major point why this solution should be preferred.

Questions? Thoughts? Hit me up on Twitter
comments powered by Disqus