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:
- Create a textbox & set its ClientInstanceName (e.g. txtTest)
- Create a button with the following clientside code for the click event:
txtTest.SetText('Test');
txtTest.SetEnabled(false); - Create a button which causes a postback.
- 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.
- The text of txtTest is blank. (it should be 'Test')
Please advise.
Hello John,
Thank you for the report. I have reproduced the issue and decided to forward the report to our developers, so they can examine it.
Your patience is highly appreciated.
Thanks,
Vest
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.
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