A
Alex Turner
I am currently using dropdown lists in a form where the user picks out a name from a dropdown linked to a secondary data source and the name's associated ID is stored. Unfortunately, the dropdown is part of a repeating section, and there can be over 200 names in the secondary data source. Once the repeating section the dropdown is in repeats about 20 times, InfoPath grinds to a halt, basically taking 30 seconds to refresh itself every single time the user picks something from the list. There is apparently a bug in InfoPath that causes all repeated dropdowns to refresh their connection to the secondary data source or something any time one of them is updated because this problem becomes linearly worse as more repeated rows are added to my repeating section, until eventually the form becomes unusable. I thought maybe SP1 would magically save me by reworking dropdown list performance, but alas, nothing.
With my users falling asleep waiting a minute for their forms to render after every time they select something from the dropdown, I've desperately tried other solutions, but they all have strange issues. I tried using SP1 filtering, having my users just enter the ID number manually, and having an expression box link to the secondary data source to display the name associated with that ID so they can check what they've entered.
The generated XPath was as follows:
xdXDocument:GetDOM("UCTS Source")/cats/subtopic/@name[../@subtopicID = xdXDocument:get-DOM()/my:content/my:descript/my:quest/my:subtopicID]
Unfortunately, the right side of the bracketed condition has no concept of the scope of my repeating section, so /my:content/my:descript/my:quest/my:subtopicID, which is apparently the only way to access the main data source ID field at that point, returns the ID from the last row in my repeating section instead of the row the expression box is in. When I change the ID in any row but the last row, nothing happens. When I change the ID in the last row, the expression boxes change identically in all rows to the name that matches the last row's ID.
I also can't use script, AFAIK, because script requires me to change the .text value of an XML node which will then be reflected in the form, requiring me to add a useless name field to my data source schema (all I want outputted in the resulting XML output is the ID).
This seems like an extremely basic thing to want to do. Assuming dropdown lists just have horrible performance when repeated, how can I look up the value from a secondary data source and display it in an expression box? If the answer is to add a useless dummy text box field to my main data source schema and use script to fill it, then there should be an option to mark parts of your data source as involved in state for the purposes of code and that will be omitted when saving the XML output of the form. Then an OnLoad event could refresh the contents of all the name fields and OnAfterChange events could update the content of the text box fields while the form is open and all that unnecessary data could be thrown away when the form is ultimately saved.
Even if you can't come up with a solution (I can't), you can at least vote on this poll:
How should Microsoft developers fix my problem? :-D
1. Fix repeated dropdowns so performance doesn't degrade as dropdowns with lots of options are repeated many times.
2. Enhance XPath expression filtering so that it's possible to access data in an XPath condition at the scope of the expression box itself.
3. Allow data source fields to be set not to save their data to the output XML for use in scripting when you want scripts to display data such as this that doesn't need to be saved.
4. All of the above
I'll start... I vote for 4
With my users falling asleep waiting a minute for their forms to render after every time they select something from the dropdown, I've desperately tried other solutions, but they all have strange issues. I tried using SP1 filtering, having my users just enter the ID number manually, and having an expression box link to the secondary data source to display the name associated with that ID so they can check what they've entered.
The generated XPath was as follows:
xdXDocument:GetDOM("UCTS Source")/cats/subtopic/@name[../@subtopicID = xdXDocument:get-DOM()/my:content/my:descript/my:quest/my:subtopicID]
Unfortunately, the right side of the bracketed condition has no concept of the scope of my repeating section, so /my:content/my:descript/my:quest/my:subtopicID, which is apparently the only way to access the main data source ID field at that point, returns the ID from the last row in my repeating section instead of the row the expression box is in. When I change the ID in any row but the last row, nothing happens. When I change the ID in the last row, the expression boxes change identically in all rows to the name that matches the last row's ID.
I also can't use script, AFAIK, because script requires me to change the .text value of an XML node which will then be reflected in the form, requiring me to add a useless name field to my data source schema (all I want outputted in the resulting XML output is the ID).
This seems like an extremely basic thing to want to do. Assuming dropdown lists just have horrible performance when repeated, how can I look up the value from a secondary data source and display it in an expression box? If the answer is to add a useless dummy text box field to my main data source schema and use script to fill it, then there should be an option to mark parts of your data source as involved in state for the purposes of code and that will be omitted when saving the XML output of the form. Then an OnLoad event could refresh the contents of all the name fields and OnAfterChange events could update the content of the text box fields while the form is open and all that unnecessary data could be thrown away when the form is ultimately saved.
Even if you can't come up with a solution (I can't), you can at least vote on this poll:
How should Microsoft developers fix my problem? :-D
1. Fix repeated dropdowns so performance doesn't degrade as dropdowns with lots of options are repeated many times.
2. Enhance XPath expression filtering so that it's possible to access data in an XPath condition at the scope of the expression box itself.
3. Allow data source fields to be set not to save their data to the output XML for use in scripting when you want scripts to display data such as this that doesn't need to be saved.
4. All of the above
I'll start... I vote for 4