+5
I am experiencing strange behavior in a repeating section. For some reason my form isn't expanding when I use a date control in my repeating section 🙄
This is the form with the repeating section without the date field.
When adding a new row the attachments control moves down like normal.
After adding the date control to the repeating section the attachments control is overlapped and disappears.
These are the settings of the control, which are default.
All ideas are welcome!
Hi,
I see some other control before the date control striked off, what is that control? Also try moving the DateTime control in the next row, it should work as sometimes the alignment of controls on the reapeating section control causes auto size issues of Nintex form.
+5
The other control is a default single line of text. I've moved the control around and made the section bigger. Unfortunately the outcome is the same. Also removing the single line of text control makes no difference. Only removing the date control seems to work.
Hi, try aligning the single line text box and date control with same left position in different rows.
And do you have any hidden controls on the repeating section?
+14
This might sound strange, but could you add the following code to your Custom Javascript just in the Settings of the Form and see if it helps?
NWF.FormFiller.Events.RegisterBeforeReady(function () {
try {
console.log("Attempting to load missing js file: 'NF.BaseDataAccessHelper.js'");
NWF$.getScript(_spPageContextInfo.siteAbsoluteUrl.replace(/sites.+/, "") + _spPageContextInfo.layoutsUrl + "/NintexForms/JavaScriptStringHandler.ashx?" + "resourceType=jsfile&" + "fileName=NF.BaseDataAccessHelper.js&" + "culture=" + _spPageContextInfo.currentCultureName);
} catch (e) {
console.log("There was a problem loading the BaseDataAccessHelper using the JavaScriptStringHandler!");
console.log("Your version of Nintex Forms may not rely on it, or there could be something configured incorrectly");
console.log("If your Repeating Sections can Add Rows without breaking, then it's unnecessary.");
console.log(e);
}
});
I've ran into an issue where sometimes a particular file (NF.BaseDataAccessHelper.js) that is needed in Classic Forms doesn't load, which in turn leaves a particular variable undefined that the Repeating Section code relies on to differentiate between the Classic and Responsive versions of Nintex Forms, resulting in new rows being added partially / incorrectly as you have shown.
The above code attempts to manually load the file, but I've yet to test this in any environments other than my own (where it absolutely works and solves this problem) so the millage may vary.
Looking forward to your reply
+2
We are on OnPrem SP 2013 and this problem started when we updated Forms to v 2.12.2. I'm getting the distinct impression no one is testing releases on the OnPrem versions. Forms that do not have a date field in the repeating section are fine.
I put MegaJerk's JS into my form, but it did not fix the problem. However, this did appear in the browser's console:
+14
Looks like your issue is in the NWF.RuntimeFunctions not being populated with a few functions on one of the properties. You could simply pop open the console (as you have it in your screenshot) and check to see where the breakage is.
NWF.RuntimeFunctions should return something, but typing in one of the following (in order) should produce an error:
NWF.RuntimeFunctions.DateHelpers
NWF.RuntimeFunctions.DateHelpers.Gregorian
NWF.RuntimeFunctions.DateHelpers.Gregorian.checkIfuserEnterforYYYY
That should give you a little insight into which file might not be loading, or where there is an issue to begin with.
If you wanted a more janky work-around you could also examine the code where it's broken (where you're throwing your error shown) and see how the Repeating Section code is accessing that particular function and simply create your own function @ NWF.RuntimeFunctions.DateHelpers.Gregorian.checkIfuserEnterforYYYY so that it returns a value which satisfies the condition. it doesn't really *solve* the problem but it can at least provide a tiny workaround until your can address whatever is wrong with the update or your SharePoint environment.
Sorry if this is very convoluted, but it's just a kinda convoluted problem.
+2
I think I fixed the problem by
1) create a template of the original form
2) create a new list from the template
3) export the form design from the original list and import into the new list.
4) the form in the new list does not have the issue; it correctly expands and does not overlap controls below it.
I did the fix above the same weekend we switched from daylight time to standard time. And I didn't test the old form before deleting it. So it is also possible this was a daylight savings time problem. If it comes back in the spring, I will do the tests MegaJerk suggested and update this thread.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.