It is not properly a bug.
When you add a calendar control to a form, CF adds a hidden input field to manage the real value of the date.
If you want to enable/disable the control using some other control event or js, you should be very careful choosing the identifier.
If you use the calendar id (e.g.: on selecting X disable #cal1) the hidden input is not disabled, if you use the calendar name (e.g. on unselecting Y disable cal1) the hidden input is disabled.
If you're not consistent you'll encounter problems. A disabled hidden input value is not submitted, for example.
Wouldn't it be better if this was managed at CF level?
Other controls use a ghost value and g2.forms.js has some code that probably manages in the proper way enabling and disabling of ghost hidden inputs.
bye
maxx
When you add a calendar control to a form, CF adds a hidden input field to manage the real value of the date.
If you want to enable/disable the control using some other control event or js, you should be very careful choosing the identifier.
If you use the calendar id (e.g.: on selecting X disable #cal1) the hidden input is not disabled, if you use the calendar name (e.g. on unselecting Y disable cal1) the hidden input is disabled.
If you're not consistent you'll encounter problems. A disabled hidden input value is not submitted, for example.
Wouldn't it be better if this was managed at CF level?
Other controls use a ghost value and g2.forms.js has some code that probably manages in the proper way enabling and disabling of ghost hidden inputs.
bye
maxx
No - what if a dev wanted specifically to control the hidden input? What you're describing is how Semantic-UI calendars and dropdowns work.
No - what if a dev wanted specifically to control the hidden
input? What you're describing is how Semantic-UI calendars and dropdowns
work.
Sorry but what's the difference with the ghost value oa a radios group control? The dev manages the hidden input in the cf UI.
For what it's worth, it appears using the #id to disable a radio group doesn't work either.
But this is already known - using the #id ONLY works for specifically disabling the specific thing with that specific id, which is exactly as it should be. This is not a Chronoforms thing this is a Semantic UI and standard HTML thing.
If you want to disable an input, use its name.
But this is already known - using the #id ONLY works for specifically disabling the specific thing with that specific id, which is exactly as it should be. This is not a Chronoforms thing this is a Semantic UI and standard HTML thing.
If you want to disable an input, use its name.
There IS a bug though - a radio group ghost is sent even if the field is disabled by name. So there's that.
If you want to use jQuery to target a field, you need to use
jQuery("input[name='field_name']")Or variations thereof. Standard Semantic UI behaviour.
There IS a bug though - a radio group ghost is sent even if the field is disabled by name. So there's that.
I believed the ghost option of the controls was there right for doing that: the "main" input may be disabled but something will be submitted anyway through the ghost input.
No it's for when you don't select anything. A disabled input should not be sent at all.
This topic is locked and no more replies can be posted.
