Forums

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

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.

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.

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.