View Full Version : [CLOSED][3.1 svn 5864] ComboBox/TriggerField Editable Config Problem

10 Jan 2010, 1:49 PM
Setting editable to false in a ComboBox somehow appears to set readOnly to true. Looking at the svn history, I believe this change was made to the source around revision 5623.

To replicate, use any example with a ComboBox and set editable to false.

What happens? The text area doesn't allow input and the trigger field becomes unresponsive.
What should happen? The text area should disallow input. The trigger field should remain active.

I think the problem is in TriggerField.js. Look at line 131 in the source. I could be wrong, but it seems like it's setting the readOnly flag there to true if editable is set to false. That can't be right.

Let me know if you need any further information.

- Jul

10 Jan 2010, 10:52 PM
The current code is correct. The code before rev. 5623 was incorrect (it assumed that readOnly==!editable).

The line 133 you mention sets the <input> to readonly if editable:false (which is correct, because no manual input is allowed).

11 Jan 2010, 2:01 AM
I think you missed what I was saying. If you set editable to false, the drop down no longer activates. How can that not be a bug?

11 Jan 2010, 2:06 AM
Indeed, I don't think I understand your problem...

The following example works just fine for me using the latest SVN build:

new Ext.form.ComboBox({
store: ['One', 'Two', 'Three'],
triggerAction: 'all',
editable: false,
renderTo: Ext.getBody()

11 Jan 2010, 2:46 AM
I tried your example and it did work. So I moved my code over into the example line by line until I found the culprit.

I was using a ComboBox inside a FormPanel. The FormPanel had a defaults specification that had a readOnly:true setting in it. In the previous version of 3.0, I think there was a bug and the readOnly value wasn't properly applied to all the components in the form. That must have been fixed at some point, so after I upgraded to the latest version from svn, my ComboBox component was getting both readOnly set to true and editable set to false which explains the behavior.

Thanks, Condor. Looks like you are right and this isn't a bug.