I am creating my first repeating section to store notes and comments on a form from successive users.
I have managed to capture the data in the sharepoint list (XML multiline text) and then format the elements of it for HTML output and store that as well, however, the entire repeating section that contained the data when I submitted it is an appropriately sized large gray area, instead of continuing to show the data I submitted in the individual fields.
I can hit the add row and it simply expands the gray space.
Should I not be able to expect another set of the fields to be available for input, even if the submitted data is no longer shown in the original fields?
I am probably missing some very simple part of the process or expecting behaviour that is not supported, as I have not seen anyone else reporting this problem.
Interesting. I have a question. Let's say your Repeating Section is connected to a Plain-Text Multiline Column called RsXML. In your workflow, when you format your XML into an HTML Table, are you saving it back to the RsXML column or are you saving it to a different column?
If you're overwriting the XML with HTML then that is likely the issue, and you simply need to save your output into a different multi-line column (likely with rich formatting so it displays as an actual table!)
If this scenario is not the case, then it would be helpful to see what the XML is before your workflow runs, and what it is after just to make sure that there isn't *something* that is changing it.
If it's identical, then the connected column isn't the issue, and I'd start looking to see if you have any rules running on the form that are attached to the Repeating Section.
No matter, post back with some more pictures and examples if none of this works, and we can take a deeper look at it.
I have had no issues when using Responsive forms but for this task I am using a Classic Form. Might that be the problem even though there is nothing I can find in the documentation to indicate that?
Well then for a next step, I recommend producing some screenshots of test data, and some xml (before and after workflow) of the test data if at all possible
Another colleague just created two forms with repeating sections in the same environment I am using; one Responsive and the other Classic. The responsive works fine while the classic does not so I think the problem may lie there. Do you think it otherwise?
I'm saying that without actually seeing what is happening, it's difficult to say! Classic forms can sometimes have issues with Repeating Sections, depending on the version and how temperamental your install is being!
If you wanna see if it's throwing errors, open the Dev Console (in Chrome this is F12, might be the same for FireFox), and then navigate to the Form. See if it throws any errors (in red) in the console.
If it has errors, they should display in red, and it might help pin down what's going on. However, if you just want to use Responsive Forms instead, that is also an option.
Thanks for the tip/reminder about dev tools.
I checked the console while performing various operations and no errors. However, I checked the elements and discovered that the repeating section elements were being hidden in the element:style and that the form in edit mode has something wrong with the people picker for the next element people picker.
Here are the snips of the form in display mode along with the element and style info and again in edit mode. Perhaps you will be able to see something that I am missing.
Thanks for your patience with me on this. I think we are getting closer to finding out the cause.
The way that Repeating Sections work under the hood is that the first row is always hidden, and is used as a "clean" baseline template for when you Add a new Row. Additionally that intentionally invisible row is given the class "nf-repeater-row-hidden" to differentiate it from the other user facing rows, so that is not an issue and that row should remain hidden.
Looking at your form, I see that you've filled something out, and then you've looked at the form in View Mode, and whatever you filled out still seems to be there. Is the Repeating Section no longer turning into a grey mess?
No, still plain grey; I just unhid the elements (see the visibility: hidden is unchecked and /* commented out */ in the style section of the element) so we could see what was taking up the space.
I have it unhidden in both in view mode and edit mode. Your statement of the template row being hidden on purpose makes the incorrect formatting of it in edit-mode less sinister. If it is the template for the people picker and not the actual people picker, that is probably fine.
However, it is still occupying space in the form when it should not, I think.
in your dev console, if you were to right click on that hidden row (with the hidden row class), and select Copy -> Copy outerHTML, could you paste the contents here?
I wanna see if there is some class missing or something attached to it that would prevent it from hiding.
You can delete the code from the Edit Mode, as it has a URL for your org in it, and is unneeded for the evaluation.
oh I just meant from the forums! I didn't want info exposed that shouldn't be is all.
Looking into this some, I see that you're Repeating Section seems to be generating that base-hidden row without the correct default css styling. It *should* have a "dispaly:none" in there, but it's missing, which is why it's showing up. Trying to figure out where that default css gets generated, but I should be able to write up a little fix for you in a moment.
I think if you find the source of the one error, you will likely find the source of the other as well.
Thanks again for your help on this.
alrighty. So I cannot discover the exact place where the default styles for a Repeating Section are being generated, but I have cooked up a solution that should work to correct the issue when the form is being rendered initially.
(Note: this is only relevant to Classic Forms!)
Open up your Form's Settings, and expand the Custom JavaScript accordion:
Once there, you can just add this code to the very bottom of whatever you already have in there, if anything:
NWF.FormFiller.Events.RegisterBeforeReady(function () {
NWF$(".nf-repeater-row-hidden").each(function(index, repeatingSection){
NWF$(repeatingSection).css({"display":"none", "visibility": "visible"});
});
});
What this does is pretty straight forward. Before the Form is Ready to use by the user, this will execute and loop through all of the Repeating Sections on the page and will make sure that the css for display and visibility are set to their correct values.
Let me know if this corrects the issue.
That made all (even the hidden row) show up properly. Just going to add another function to remove the top row.
From everything you've typed, the issue was that the fundamental hidden row (the row that has the class "nf-repeater-row-hidden") was not being set to "display:none", and had its "visibility: hidden". If the above code I posted isn't correcting that, then you might just have something else interacting with that control in a way that it shouldn't be.
Any who, good luck!
- the top row is being displayed.
- all the rows visibility are set to hidden. (My modification of your code addressed this).
All that is left is to make the top row go away, which your code should have done but did not. I think we are really close and there is some small thing left to do to fix this.
In the Custom CSS section, I added
.nf-repeater-row-hidden {
display: none;
}
and that removed the top row.
Thank you for getting me here and for your patience.
I will mark the earlier post as a solution.
I believe the reason why the initial solution I posted didn't work is because that entire fundamental hidden row isn't being generated correctly, and because all subsequent rows are generated from it, it affects their control visibility as well.
It's good to see that you found a workaround for your problem.
I'd be curious to know if this issue is persistent across your entire installation or just the particular form you're working on. The only way I could think to test it would be to make a Test List, start a new Classic Form, add a Repeating Section and a dummy Single Line Text, and just see what it looks like in the Preview. if it works correctly, then perhaps this is something limited to the troublesome form in question, however if it persists and is displaying incorrectly, perhaps it's something that could be corrected with a Nintex update or by taking it to Nintex directly (with a trouble ticket).
No matter, at least it's working now!
No matter, I think we are closing in on what is probably a deployment-specific problem.
I will test the same on simpler forms as you suggest.
Thanks again. Cheers.
good day, can you post the final solution, cause mine is doing the same thing and it's not visible unless i change the «hidden» to visible in the dev tools.
Custom Javascript
// this javascript makes every row in a repeating section visible (including the properly hidden one with the repeating context which shows up as blank space in my version)
NWF.FormFiller.Events.RegisterBeforeReady(function () { NWF$(".nf-repeater-row").each(function(index, repeatingSection){ NWF$(repeatingSection).css({"visibility": "visible"}); }); });
Custom CSS
.nf-item {
}
.nf-item-alternating {
background-color: white;
}
// place the following command below the two commands above (which are already there). It makes sure that the first, properly hidden, row of the repeating section is not displayed at all.
.nf-repeater-row-hidden {
display: none;
}
These two steps should resolve the issue if your setup is similar to mine.
Reply
View our Community Site Map
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.