All ASP.NET Web controls have the Enabled property, which, when set to False, renders the associated HTML element as “disabled,” which grays it out and prohibits the user from interacting with the control. For example, in IE a disabled TextBox's text is grayed out and the user cannot focus on the TextBox, change its value, etc. (In FireFox, the text and background of the TextBox are both grayed out.) Often, web developers will use the Enabled property when displaying a read-only or locked data input screen.
However, if you examine the TextBox class you'll find a ReadOnly property in addition to Enabled, which can understandably be a bit confusing especially considering that the other standard input Web controls - the CheckBox, RadioButton, DropDownList, RadioButtonList, CheckBoxList, ListBox, etc. - lack the ReadOnly property and offer only Enabled. If you set the ReadOnly property to True for the TextBox you'll find that the text/background is not grayed out (as with setting Enabled to False), but that the text content is uneditable (as expected per the property's name).
So what's the difference between these two properties and why do both exist? There are two differences between these two properties, a trivial difference and a subtle, profound one:
- The two properties emit different markup. When you set Enabled to False, the TextBox injects the attribute disabled="disabled" into its rendered HTML. When you set the ReadOnly property to True, the attribute readonly="readonly" is injected.
- According to the W3C spec on HTML forms, disabled controls are NOT "successful," while read-only controls MAY BE "successful." A "successful" control is one whose name/value pair is sent back to the browser through the POST headers or querystring. Therefore, disabled controls are NOT sent back to the ASP.NET page, while read-only controls may be, depending on the User Agent. (In my tests, both IE 6 and FireFox 1.5 send along the read-only TextBox input.)
For most scenarios, this subtle difference in postback between read-only and disabled controls is not an issue... it becomes an issue, however, when using these controls in a page with its ViewState turned off and when these control values are set programmatically.
Since disabled input control values are not sent back when the form is submitted, the only way that the page can remember these values is if they are specified statically (i.e., specified directly in the markup portion of the ASP.NET page in the TextBox control's declarative syntax) or if they are set programmatically and ViewState is enabled for the control and page. If ViewState is disabled and the control value is specified programmatically, it will be lost on postback because the actual value in the disabled TextBox won't be sent back to the server (because it's not a “successful” control) and the server won't remember the value in ViewState since ViewState is disabled).
If you encountered this problem in ASP.NET version 1.x you might have found the TextBox's ReadOnly property and used that instead of setting Enabled to False. You could still have a page's ViewState disabled and set a read-only TextBox Web control's Text property programmatically because the TextBox value is sent back through the form submission for read-only controls. However, in ASP.NET version 2.0, things change just a bit, as noted by Rick Strahl in his blog entry ASP.NET 2.0 ReadOnly behavior change when EnableViewState is false. With 2.0, the TextBox control's ReadOnly property's behavior has changed slightly. From the technical docs:
The Text value of a TextBox control with the ReadOnly property set to true is sent to the server when a postback occurs, but the server does no processing for a read-only text box. This prevents a malicious user from changing a Text value that is read-only. The value of the Text property is preserved in the view state between postbacks unless modified by server-side code.
What happens is that the client sends along the value of the read-only TextBox through the form values, but the ASP.NET 2.0 engine does not take that value and assign it to the Text property of the TextBox on postback to help protect against a malicious user changing the read-only TextBox value themselves. But this brings us back to our earlier problem - if the value isn't specified in the postback (or is ignored, in this case) and ViewState is disabled, the value will be lost. Eep.
Rick's workaround was to just manually read the value from the request headers (this.TextBox1.Text = Request[this.TextBox1.UniqueID];), which poses a security risk and introduces the problem that 2.0 addresses. The optimal approach is to requery the value from the database (or wherever you initially got the programmatically-set value for the read-only TextBox).
The moral of this blog post is that if you have read-only data you can use either disabled or read-only form fields, it really doesn't matter whether or not you receive back the value of the form field in the form's submissions. It shouldn't matter because you shouldn't be trusting/using that data to begin with! If you have read-only data, don't re-read it from a data stream that the end user can tinker with!