Bug Report B202991
Visible to All Users

ASPxTextBox - When an editor is disabled on the client side, its Text is cleared after a postback

created 14 years ago

Calling the clientside SetText method on an ASPxTextBox followed by SetEnabled(false) will result in the text being blank instead of the text specified upon postback. This happens only in Firefox.
Steps to reproduce:

  1. Create a textbox & set its ClientInstanceName (e.g. txtTest)
  2. Create a button with the following clientside code for the click event:
    txtTest.SetText('Test');
    txtTest.SetEnabled(false);
  3. Create a button which causes a postback.
  4. Click the clientside button created in step 2, then click the postback button created in step 3, and set a breakpoint in the Page_Load event.
  5. The text of txtTest is blank. (it should be 'Test')
    Please advise.
Show previous comments (1)
DevExpress Support Team 14 years ago

    Hi John,
    Thank you for your patience. We have examined your issue and found out that this behavior is correct. By design, if a control is disabled, it means that its value cannot be changed on the client side: nether by a user nor by code. If you want to change the editor text, you should enable it.
    By the way, would you please describe your scenario in greater detail? We try to find an appropriate solution for you.
    Thanks,
    Marion

      I agree with your reasoning, but this is not the case. The value is being changed before the textbox is being disabled. Basically, the ASPxTextBox value is being lost once the client-side method SetEnabled(false) is called. This happens only in Firefox.
      I would agree with you if the SetEnabled() method was called before the SetText() method, but in this case it is vice-versa.

      DevExpress Support Team 14 years ago

        John,
        Thank you for your feedback. Let me explain what happened in your scenario.
        You call the SetText and SetEnabled methods thus disabling an editor. As a result, the input (in which ASPxTextBox is rendered) becomes disabled. Then, you perform a postback to the server, and the browser collects values of all enabled inputs. In the current case, the browser automatically determines how to collect the values. As different browsers may behave differently, you see different results. Thus, the browser does not contain the disabled value in a collection that is sent to the server.
        The only fix we can apply is to add a new hidden input to the ASPxTextBox rendering and synchronize it with the server. Even though the enabled property will not be used, this hidden input will be always rendered. This will result in the increase of the ASPxTextBox rendering and script code. Therefore, if a user has a lot of editors, this increase may affect performance distinctly. We prefer to avoid this unnecessary performance influence. I hope you understand our position.
        If you want, you can render a hidden input yourself and synchronize it with its server-side state. It will allow you to achieve the desired result for the current scenario and avoid possible performance issues for other ASPxTextBox controls.
        Thanks,
        Marion

        Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

        Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.