Please run the attached sample web form with Microsoft Internet Explorer 8, FireFox 3.6 and Google Chrome 6.0 and try the following:
- Click on the button "Fuente". A client-side process runs and sets txtRefFuente equal to "1".
- A PopUp window will appear with 2 buttons: "Asignar" and "Cancelar".
- At this moment you can see txtRefFuente with a value of "1".
- Click on the button "Asignar". The popup is closed and a server-side process is executed.
- The value of txtRefFuente is lost when the form is run with Chrome and FireFox but it is kept if the web form is run with Microsoft Internet Explorer and Opera.
Is this an issue that has to do with DevExpress controls?
Respectfully,
Jorge Maldonado
I forgot to include the sample file, here it is.
Regards,
Jorge Maldonado
Hello Jorge,
Thank you for sending the source code to me. I have reproduced this behavior. However, I need to discuss this behavior with our developers, so I will still leave this report as active. We will answer you as soon as possible.
Thanks,
Mike
Hello Jorge,
Please accept our apologies for this delay. Our developers researched this issue. We use different approaches to disable our editors via the ClientEnabled property: For the FireFox and WebKits browsers the disabled="disabled" attribute is used to prevent editor use. When you submit a form to the server, the value of the "disabled" inputs are not posted. I have attached a sample project and video to illustrate it.
As a possible solution, it is recommended to enable the ASPxTextBox editor via its SetEnabled method before postback (by handling the ASPxClientButton.Click event).
Thanks,
Mike
I do not really need to disable the textbox, my main situation is to make it invisible so, based on what you tell me, it would be easier to set the ClientEnabled property to true in the aspx form and that would be all. Thank you for the information about how Firefox and Chrome work.
With respect,
Jorge Maldonado
So, this means that any DevExpress control (comboboxes, labels, textboxes, listboxes, checkboxes, memos, etc.) with its ClienteEnabled property set to false will not be sent to the server in a postback. Is this correct?
Regards,
Jorge Maldonado
I am checking my project and I see that I set the ClientEnabled property to false in several places and, when I run it with FireFox/Chrome, they do not work correctly; nevertheless the controls must remain visible. I suppose that I can use the ReadOnly property and set it to true instead; all I need is to restrict access to such controls. Am I right?
Regards,
Jorge Maldonado
Hello Jorge,
Thank you for the response. Here are answers to your questions:
>> So, this means that any DevExpress control (comboboxes, labels, textboxes, listboxes, checkboxes, memos, etc.) with its ClienteEnabled property set to false will not be sent to the server in a postback. Is this correct?
Yes, all our editors that have an <input /> element (such as the ASPxTextBox, but not the ASPxLabel) and the ClientEnabled property equal "true", so you should not post their values to the server during a postback (the standard <input /> does not do it either).
>> I suppose that I can use the ReadOnly property and set it to true instead; all I need is to restrict access to such controls. Am I right?
Yes, if it is necessary to restrict access to some editor, set its ReadOnly property to "false".
Thanks,
Mike
I performed and additional test on this issue so I wrote a small web form that includes an ASPxTextBox and 2 ASPxButtons. Such test includes the following:
TEST 1:
* Textbox's ClientEnabled property="false".
* Button1's AutoPostback="false" with CLIENT-SIDE code to set textbox's value to "1".
* Button2 only performs a postback.
* The value of the textbox IS lost after postback.
TEST 2
* Textbox's ClientEnabled property="false".
* Button1's AutoPostback="true" with SERVER-SIDE code to set textbox's value to "1".
* Button2 only performs a postback.
* The value of the textbox IS NOT lost after postback.
In both cases I first clicked Button1 to set the textbox's value to "1" and then clicked Button2 to perform a postback.
So, I see that the issue is present when assigning a value to the textbox through client-side code but not when its value is set through server-side code.
I will appreciate your comments.
With respect,
Jorge Maldonado
Also, can you please tell me where to find which DevExpress controls have an <input /> element?
Regards,
Jorge Maldonado
I guess I know which controls have an input element. If a control has a client-side GetInputElement method then is has an input element. Is this correct?
In this post we have been talking about the issue of the ClientEnabled property and a postback using FireFox and Chrome; the value of any control with an <input /> element is not sent to the server by these internet browsers. Does this also apply to the client-side SetEnabled method? It seems to me that it does not because I have tested such a situation and I did not get any trouble.
Please advice.
Best regards,
Jorge Maldonado