Presumably the completed fields in a COTG form are persistent by nature of some JSON or DB storage when one revisits the form as you can see them pop into view moments after an already visited form loads.
My question is: What is the event which drives this behaviour as I am trying to prevent an onLoad function from occurring in a form which has previously been initiated but from all tests thus far, it appears my check for that ‘already active’ flag are firing before the previously filled values are being loaded in by COTG? If I knew what event the existing data load was bound to, I could bind my check to the same or subsequent event.
I’ve tried writing ‘true’ to a hidden field but on load, the field reports the default value, not the written one.
In summary, how do I ensure my startup function only runs once?
Ok this has taken me further down the rabbit hole. Interestingly, it seems that COTG is storing the values of the fields once the form is commenced and then this data is restored to the fields if/when it is revisited in the My Library section of the app.
However, the HTML and all other components to the form are loading as default each time so it is as if I get a new form each time and then the values are populated from the temp storage. The problem with this is that if conditions have hidden fields based on the data entered, this is then ignored on the second visit to the form and those fields are showing again (or vice versa as the logic might have it).
Is there a way to make the changes to the DOM persistent as well as the data retention?
@Phil, I could use a hand here. I have tried using savestate to store a variable, let’s say formActive and set this to true which I then retrieve using restorestate and check before running my function but the same behaviour occurs where it appears my code in document.ready() is running before any of those events are fired.
What am I missing? Presumably something in the order of execution…
I have actually managed to solve this one and the answer is quite frustrating (as it appears some of the issue was between the keyboard and the chair). I thought I had managed to get it working before and then I couldn’t so convinced myself that I was wrong but actually, it’s rather more simple that I had imagined…
Previously I had been writing a value to a p tag or input tag but only one with an id and then I was trying to target this id as my test for whether the form had been previously active or not. The answer (and I should have known this!) was to give it a name attribute as anything with a name is automatically loaded from the JSON data when restorestate is fired.
This means that now, with a short delay (500ms) before running my formSetup function, I can now check the value of the formActive input and perform setup steps accordingly.
I’m sure there is a more elegant way of getting the run order correct and triggering the desired behaviour on the correct event(s) from the app but in the interest of progress, this works for anyone else who runs into the same problem.