BUG, RadioGroup event change is messed up.

[predator]

Hello Team,

RadioGroup change event is having several issues:

1. Event is fired two times on each change(beside initial change in the group if no radio was configured as default.

2. newValue is object with property named after the name of the radios instead of holding the value itself.

3. As each change in the radio group fire the event two time. The first time newValue.radoName is array with the oldValue and the newValue. The second time is only the newValue.

Consider following work around handler as example:

...    
onFlexibleShiftsChange: function(field, newValue, oldValue, options) {        
// Overwrite parameter as it is passed as object instead of value        
var newValue = newValue.flexibleShifts;
        
// Event is fired 2 times on change, first time the value is array with the old and new value        
// second time is only the new value. Check if this is the array case and skip it.        
if(!Ext.isArray(newValue)) {
     if(newValue === 0) {
            field.next().show();
      } else {
            field.next().hide();
      }
}
 ... 

Best regards

[mitchellsimoens]

We will see what we can do.

[aw1zard2]

Make sure the field is the exact same for both events.

Radio's used to use check event which fired twice once with the old and once with the new.
Since 4.x doesn't have the check event for radio's. I'm wondering if the change event picked up the old correct behavior.

http://www.sencha.com/forum/showthre...l=1#post507064

[predator]

Make sure the field is the exact same for both events.

Radio's used to use check event which fired twice once with the old and once with the new.
Since 4.x doesn't have the check event for radio's. I'm wondering if the change event picked up the old correct behavior.

http://www.sencha.com/forum/showthre...l=1#post507064

Not sure what you mean, you are digging too deep i think. My case is plain and simple radiogroup with two radios. Change is happening by a mouse click and not being programmed with setValue().

The expected behavior IMO is that the change should fire only once and with newValue being the newValue.

Thanks

[aw1zard2]

If the change event behaves like the check event the check event used to get fired twice either by mouse click or setValue().

Make sure the field being passed on the event is the exact same one.
Can test it with alert(field.getId());

[aw1zard2]

Looking in 3.4 api the radiogroup change event used to be this.

change( Ext.form.RadioGroup this, Ext.form.Radio checked )
Fires when the state of a child radio changes.
 Parameters
       this : Ext.form.RadioGroup
       checked : Ext.form.Radio  The checked radio

In 4.x it's using the standard on Change event from Ext.form.field.Field.
Which is wrong and shows the standard behavior your noticing in that one got unchecked and the other one got checked.
Reason I said check the fields coming in cause I bet the getId() is different both times the event is fired.

[predator]

I understand what you mean... the event listener is attached to both radios thus its get fired twice.

But again you are digging too deep, the how's and why's in this case are something that the maintainer should deal with I think. All I am doing here is to report something that does not seems to behave as expected in my opinion.

Thanks for your feedback.

[mitchellsimoens]

I understand what you mean... the event listener is attached to both radios thus its get fired twice.

But again you are digging too deep, the how's and why's in this case are something that the maintainer should deal with I think. All I am doing here is to report something that does not seems to behave as expected in my opinion.

Thanks for your feedback.

And this has been reported since I first posted. It is changing from on radio to another so to the radio group there is only one value change

[predator]

My reply was to aw1zard2 as he is digging into hows and whys for this. I already have demonstrated workaround and until this gets implemented in the next release there is not need to dig it up further on our side. Yes we can overwrite the library files and fix it, but then it will brake on the next release. So it is better to do a simple workaround in the implementation until the core gets fixed.

I am not questioning that you have reported this to the dev team, just following up on the conversation.