What is JotForm?
JotForm is a free online form builder which helps you create online forms without writing a single line of code. No sign-up required.
At JotForm, we want to make sure that you’re getting the online form builder help that you need. Our friendly customer support team is available 24/7.
We believe that if one user has a question, there could be more users who may have the same question. This is why many of our support forum threads are public and available to be searched and viewed. If you’d like help immediately, feel free to search for a similar question, or submit your question or concern.
Run time constants. Feature request or bug report?Asked by NRCsupport on March 18, 2014 at 08:58 AM
In another thread "Default values lost in edit mode" I complained that default values on fields were lost on going in to edit a submission. Earlier I had reported the same problem with a spinbox field.
I need to be able to set up a constant value in my form, which I can use within calculations, and to be displayed or hidden according to conditions, and to be passed to the thankyou url and the notification/response emails.
An example is the price for entry to an event. This may be used several times within the form and responses, but should only have to be typed in once, so that it is easy to change it later.
I had assumed that if I put the value as the default value in a read-only field, I would be able to do all the things I need to with it, including displaying or hiding it according to a condition.
But it turns out that if the condition hasthe field hidden at the time of submission, then the field is cleared to "empty" rather than back to the default value. Which means that on reopening the form to edit the position, the field comes up blank, as do any calculations based on it.
I regard this clearing of the fields as a bug, which I hope can be corrected. If it is not accepted as a bug, then please add a "run time constant" field, i.e. a field whose contents are defined in the form editor, cannot bemodifed by user, and are not cleared on submission when hidden, but which otherwise is handled just like any other simple field (i.e. use in calculations, display/hide by conditions, use in thankyou url and in notification/response emails)
(Q:) I complained that default values on fields were lost on going in to edit a submission.
(A:) If it's a bug I think the other thread you have pretty much covers it already as there is no need to duplicate a thread about what seems like the same issue that you already have opened elsewhere.
(Q:) An example is the price for entry to an event. This may be used several times within the form and responses, but should only have to be typed in once, so that it is easy to change it later.
(A:) I think I sort of get what you are seeking but I'm not so sure that you first example is feasible since technically this is already possible on the form. You can do this when you input data into the form then by duplicating the same input it retains this value. The only time this would not work is in the payment integration since only one can be used on the form unless you implement it as a multi-purpose form.
(Q:) I had assumed that if I put the value as the default value in a read-only field.
(A:) It's not going to work that way since it's marked as " Read-Only ". Read-Only Mode only allows it to be read as stated by the Mode name which is why that happens. If it's for anything other then that such as prepopulation, copying, changing, etc, etc, then it would not be able to grab the data from the said field because of this function and the only way to make it work is to disable that. This is the same for various other platforms as well.
(Q:) But it turns out that if the condition has the field hidden at the time of submission, then the field is cleared to "empty" rather than back to the default value. Which means that on reopening the form to edit the position, the field comes up blank, as do any calculations based on it.
I think that this may be happening in relation of the " Read-Only " function. It is probably not carrying over the value fully depending on how you have the condition set.
Before we can decide which way to go with this I think it would be best if we could take a look at the example form you've run into this problem with. I think it's important to first understand the the Conditions you have set for this to double-check it further since right now I am not certain about that and it seems as though a conflict may be occurring.
Anyhow, I'm going to check this some more to try and replicate it based on your above problem and we will await a response from you about it incase you are able to provide us more details about how you came across this more. Then I think we will have enough thought and detail to figure out which way to go on this matter.
I started trying to check this further but either I'm not understanding what you mentioned or perhaps your read-only and condition may be creating a problem.
I made a couple fields on a test form with default values but they all carried over and were seen as intended even though the I had a few hidden and marked as read-only. I also tried playing around with them but I'm still getting the same results each time. I am wondering if you have your Hide Empty Fields Option " Enabled " since I know that can also affect this.
What steps were you taking that lead you to this problem? Can you please describe them more?
Thanks, and sorry about appearing to duplicate a thread. I got the impression that nothing might happen from my previous thread.
I'll try to be clearer.
I've made a smaller form to show the problem. It is at http://form.jotformpro.com/form/40766660359968
The problem does NOT occur when filling the form initially. But if you use edit_link to go back in and edit the submission, fields that were hidden by a condition at the time of the original submission come back empty rather than containing the default value that they originally contained.
This does NOT seem to happen with hidden fields put in by the hidden field widget, or with normal fields put in as text boxes and set as hidden in their properties. They correctly retain their default values when reopened through the edit_link. (note the fields "who are we" and "our email" appear correctly in the Edit: emails).
You certainly can set a default value in a read only field. It does (as I would expect) set the field to that value, and does not allow the user to alter it. In this form the field "Price Each £" is set to the price per place when setting up the form. It is transferred to the emails (and on my real form) to the thankyou url. It is used in the calculation to give "Total cost £". It could also be used in other calculations, such as discounts.If we change the price or decide to use basically the same form for an event with a different price. I only need to alter that one field in the form design, and everywhere it is used throughtout the form, the emails and the thankyou page, will be updated automatically
The field "Number of places" accepts values from 1 to 8, with a default value of 1. These three fields are only shown when "Do you wish to attend our quiz night" is "yes". When you set this to yes for the first time, the three fields correctly show the 1 (the default) 12.50 (the read-only default) and 12.50 (the product of those two).
Now try this. Set "Do you wish to attend..." to "no" and complete the submission.
Then get your notification or response email, and click on the edit_link. The form reopens for edit. Change "Do you wish..." to "yes". Thosethree fields appear, but they are all blank. When you enter a number in "number of places", the "price each" remains blank, and the "total cost" field goes to 0.00, presumably regarding the empty "price each" as zero.
I hope this is sufficient for you to investigate further. Thankyou
By the way the form isset to hide empty fields in the emails. But I've tried cancelling that, and the problem described still exists
If I understand your requirement correctly, you are saying that the data of fields hidden through a condition (not hidden box) is not submitted and when you come back to edit the submission, it does not populate the default value. Is that correct?
I believe, this is not a bug and that is how it works currently. When you hide a form field, that default value of that field is not part of the submissions and saves an empty string. That is the reason when you load your form through edit link, it loads the values from the submission records and hence displays empty string.
I hope I understood your question correctly.
The only workaround I can think of is to store the default value in "Hidden Box" widget, which does not lose the default value upon submission.
If you want, I can send this as a feature request but I am not sure how feasible it will be. Do get back to us if you meant to ask something else.
Yes, you have understood my question correctly. I believe that if a submission has an empty field, then on opening that submission for editing, the field should be given its default value if there is one. An alternative would be to insert the default value at the moment when a condition causes the field to be displayed and it would otherwise be empty.
Strangely a field that is set as hidden in the form editor does retain its value (just as is done for fields created by the hidden box widget). It is only when it has been hidden by a condition that it gets cleared. To me, this difference in behaviour is illogical.
At present if a calculated field gets cleared because it was hidden at the time of submission, then when reopening to edit the submission, that field remains blank until any of the fields referred to in its calculation are modified. In another thread I mentioned a messy way to get round that particular problem.
If, as you say, the current behaviour is intentional and cannot be changed, then I repeat my request for the addition of a "run time constant" field, i.e. a field whose contents are defined in the form editor, cannot be modifed by user, and are NOT cleared on submission when hidden, but which otherwise is handled just like any other simple field (i.e. use in calculations, display/hide by conditions, use in thankyou url and in notification/response emails)
By the way, unless there has been a change in the last few days, the calculation widget does not allow the inclusion of "hidden box" fields, but it does allow hidden normal fields.
I kindly ask you to open a different thread regarding the hidden box fields not being used with the calculation widget.
I forwarded this feature request to our developers. You will be notified through this thread once they have news on this matter.
Thank you for your input.
Thanks. I already had an open thread on the hidden box topic. I notice that it was awaiting my response, which I have now done.