DotNetCurry Logo

Using InfoPath in SharePoint for a Table Data Entry view (similar to ASP.NET repeater control)

Posted by: Todd Crenshaw , on 5/7/2014, in Category SharePoint
Views: 21757
Abstract: This article shows how to use InfoPath for a table data entry view simulating the look of the ASP.NET repeater control. This article uses the rules and format controls in InfoPath.

One very difficult task in SharePoint is to create a list entry form which gives a properly formatted table view of data, during entry. Here I’ll demonstrate how this can be done to give the form user, an easy way to view the data selected, before submitting the form.. You can compare it with the ASP.NET repeater control, an auto expanding table view of data. This control gives the entered data, a table format which is easy to read. The table auto expands as needed. This article shows how to accomplish this same view of the data using the rules and format controls in InfoPath.

I am using SharePoint 2010 Enterprise and Microsoft InfoPath Designer 2010.

Requirements for this project: A SharePoint list entry form with 4 fields pulling data from another source, in this instance I’m using another SharePoint list. The table must expand from 1 to a known number of maximum entries. The data must be in a table view for ease of reading. To accomplish the requirements, we’ll need to use a combination of rules, list columns, and a very small piece of XML to accomplish. As in all scripted rule controlled, and out of the box functions there are limitations, but we’ll work with what’s available.


Let’s setup our list first.


Now we have our list, so open the list form in InfoPath. I usually delete the entire boiler plate form and start from scratch. I’ve placed all my list columns into my form.


Out of good form design, I typically lead the user through the form by locking each control. I do this until a required control meets its requirements for selected data.

Here the Location control is the only active control when the form is initially opened.


This rule disables the Name (Well Name Selection) drop down until the Location (Location Selection Filter) contains data. The rule is then copied and applied to each additional selection and pointed to the previous entry for validation.

I also usually use some sort of filter to limit the selection list length. In this project, there are over 6000 items in the SharePoint list I’m pulling the “Names” from. Pulling a drop down selection with 6000+ items would immensely slow the selection process. In the form I’ve used a name “Location Selection Filter”. The same data in the list where I’m pulling the data from uses “MeterField” as the column name where the data I need to compare is at.


This means I want the form to display all the “Names” where the “Location” I selected in the form, is equal to the “MeterField” column in the list that contains the “Names”. This causes the drop down to contain only the “Names” for the “Location” selection. It’s a simple filter and easy to build.

InfoPath allows the dragging of fields onto the form. By doing this, InfoPath sets the box to a default size. The default size from InfoPath is 50px in height.


Unless you’ve worked with form designers, you may not realize that this is adjustable by more than just entering a fixed number. This includes not just using the drop down selection, because there is no selection to allow the box to expand. What will end up happening is that data entered will wrap in the box and a slider bar will appear on the right hand side of the box. This is not the results we want. This sounds somewhat silly but just type “auto” in the Height box. The box resets to 1 line and will auto expand as data is entered into the box.


I set up the columns I want in the same way so they auto expand in the form.


To get these fields populated, I use a single rule with 9 actions. The rule is setup on the “Still Down” (Yes/No) selection.


Upon selecting Yes or No, the rule is activated.

Here’s the rule and its actions.


I use the InfoPath concat function to format and join the data in each one of the four columns.


Here’s a problem with using concat, it joins data end to end, so I end up with a continual string of data instead of separate lines. Also, how do you keep each data set submitted from over writing the previous data?

Both of these problems are in the concat line above if you look close enough. The resolution was really easy enough to figure out. To keep the data from becoming one continual string, a CR/LF must be inserted into the concat statement. However, CR/LF or control characters can’t be typed into the concat statement. That would be too easy. Here’s how you get this done. Create a text file with the following content:

<?xml version="1.0" encoding="UTF-8"?>

Rename it to whatever you wish. I named the file CRLF.XML. In your InfoPath form, select the Data tab and Data Connections. Next select add a connection with the Add button. Click Next on the next screen to Create a new connection to > and Receive data. On the next screen, InfoPath needs to know what the data source is. Select XML document. Select Resource Files…, Add, and navigate to the folder where the .XML file is located. Follow the prompts.

Now when building a concat statement that needs line feeds to separate each line of data, use the Insert Field or Group… button.


In the window that opens, in the lower left select the “Show advanced view” option. From there, select the Fields drop down and the CRLF will be displayed.


Selecting it and then selecting the CR/LF that will display the Field selection, will insert a carriage return/line feed into the concat statement. This stops the line wrapping and makes each data set individual lines.

Next problem – each time a new selection is made, the prior data is overwritten. The data is being concat into the field. The solution - why not just concat what’s already in the field? With this simple setup, any data that was already in the field is now appended.


In this instance, all new data ends up at the top of the field. Reversing this would put it at the bottom. IE..concat(Wells Down Column1, @crlf, Well Name Selection).

Now repeat this same action for the Wells Down Column2, 3, and 4 in the rule.


And we end up with this in the form:


This will continue to expand up to the maximum limit of entries allowed in the Wells Down1, 2, 3, and 4 boxes. In this project up to 20 entries can be made. The InfoPath form expands cleanly and maintains an easily viewable format. We’re not done yet though. The selection fields must be cleared otherwise incorrect data may be selected. This is accomplished with the last four actions in the rule.


The only field that is not cleared is the Location. This speeds entry for this project if the location selection is the same for the next entry.


Total time to build once the technique is learned is about 15 minutes. Using the rules, actions, and functions built into InfoPath and adding in the .XML CR/LF capability makes creating good looking InfoPath forms for SharePoint a breeze. The Power User is a highly underutilized strength in the SharePoint field. By learning techniques such as the one outlined here, even small companies can produce highly functional SharePoint entry forms. In future posts I’ll include what I call near application level site design. These use 3rd party workflow extensions, email parsing, and data sync tools to process data, much as an application would. These include a work order system, fleet vehicle management system, fleet pool reservation system, automated security for records and data management, and much more, all without .NET code. This demonstrates that the simpler SharePoint project requirements can be met with current, off the shelf tools, at a lower cost and can typically be deployed in 1/3rd the time.

Was this article worth reading? Share it with fellow developers too. Thanks!
Share on LinkedIn
Share on Google+
Further Reading - Articles You May Like!
Todd Crenshaw is a Systems and SharePoint Administrator for an energy company located in Dallas, Texas. Todd has worked in IT for 30+ years and has experience covering all Windows platforms, several flavors of UNIX, and IBM’s AS/400 series. On the application side, Todd’s managed SharePoint 2007/10, Exchange 6.x, several different flavors of enterprise backup software. Over the past 6 years Todd has been involved with SharePoint in the administration and Power User roll where he has pushed the limits of SharePoint workflows and InfoPath. Todd also provides training through his co-partnered company Todd can be reached through LinkedIn and maintains his own SharePoint blog at here

Page copy protected against web site content infringement 	by Copyscape

Feedback - Leave us some adulation, criticism and everything in between!
Comment posted by Michael Wiebrand on Wednesday, May 7, 2014 10:55 AM
You Dotnetcurry guys are on a roll, Great stuff!
Comment posted by Mark Pritchard on Friday, May 9, 2014 2:02 PM
Any new features in InfoPath/SharePoint 2013 that makes this task easier?
Comment posted by Todd on Friday, May 9, 2014 4:05 PM
Mark, we've looked at SP 2013 and so far we're not really liking what we see in it. It appears that Microsoft is pushing social networking, which though collaboration is a part of, it's less business oriented than we feel it should be. Ultimately we're holding off on SP 2013 until later in the year to take another look. However to answer your question, that I know of - no, InfoPath still has to be tricked into this method of displaying columns of data in this manor. It would be nice to be able to insert a list view into an InfoPath form and use filters to display only what we need, but I haven't been successful at finding a way to do this yet. I'm always looking for a new way to skin a cat though!
Comment posted by Fletcher on Thursday, June 19, 2014 12:57 AM
Thanks for the write-up. I too am interested to know how InfoPath works in SP 2013. Are you planning to write anything on it and compare it with SP 2010?
Comment posted by Todd Crenshaw on Thursday, July 10, 2014 8:33 AM
hello Fletcher,

Since Microsoft has announced that InfoPath will be phased out we've looked at how this will affect our SP 2010 farm as well as what effect this will have in the future with SP 2013. InfoPath at this time still works with SharePoint 2013, rules and all work fine. However the move is to put the entire form design into Visual Studio. There are pro's and con's to this. The first thing I didn't like is that my visual design window is now gone. I can't view what I'm designing in Visual Studio. I have to publish and then take a look at it. There is a logical (to some degree) reason for this. Microsoft appears to be pushing cloud usage for all their software, this includes SP 2013 and beyond. This means HTML 5 will be a requirement. Formatting like we've done in the past with InfoPath is no longer an option. It's nearly impossible to format a form in InfoPath and have it represented correctly on a computer monitor, tablet, and cell phone. Thus, Microsoft doesn't give us the ability to view the design format in Visual Studio. The concept now is to include the elements (Name:, Date:, Selection:, and so on) on the form and allow the form to be formatted to the devices dimensions. The good is that it works. The .net developer that I work with has created an SP 2013 site in the cloud and created an entry form. The form reformats to my iPhone, my Nexus 7, and to my computer monitor really well. The drawback is that if a department comes to you with a paper version of a form and says we want the online form to look identical to the paper one - well, in Visual Studio forget it. However you can still use InfoPath to design the form just like the paper version, but it's not going to format correctly on mobile devices. Another concept to add to the Visual Studio type forms is that the designer needs to minimize as much as possible what is on the form. The 20 questions is out the door. No one wants to go through 20 questions on a form entering the information from a cell phone. The forms therefore should be absolutely as short as possible, with as few entries as needed to get the job done. As much as I'm against SP 2013's enterprise social media garbage, I've found that the cloud version is giving me some fantastic opportunities with its flexibility of design and connectivity. There's more to come on that in the future as I'm just getting into it now, but so far I like what I'm seeing. What I see in the future is if the form is going to be available only to computer users, then using InfoPath is fine. If the form is to be used by mobile users then the Visual Studio method of design is most likely going to be better. In some cases I can see finding a way to call the two different forms on the same list, if that's even possible. I haven't tried that. One other thing needing to be mentioned about the Visual Studio method - since I'm not a programmer, I'm going to have to learn an entire new method of design using the Visual Studio method. Also, several features already have shown to be missing in Visual Studio that are very common in InfoPath. For instance the .net developer helping me learn this new method of design was complaining that the buttons to add and save a new entry into a list were available in the plug-in's for Visual Studio. However he had to write his own Java Script to include a delete button. This shift to Visual Studio is going to cause a lot of Power Users to be very angry with Microsoft. I know I'm not pleased about this, and the eventual loss of InfoPath. You don't create an easier way to create these things to make SP powerful and then pull the rug out, but that's what has happened. The choice is pretty simple though, learn the new Visual Studio method, or move on. InfoPath is going to be history and I expect we've seen the last SharePoint Designer too.
Comment posted by Fletcher on Monday, July 14, 2014 9:33 AM
Wow! Thanks Todd for explaining it so well. I too had a strong feeling that we won't be seeing much of InfoPath going forward. You mentioned that the cloud version is giving you some fantastic opportunities with its flexibility of design and connectivity. Can you elaborate?
Comment posted by Todd Crenshaw on Wednesday, July 23, 2014 3:32 PM
Fletcher, the connection flexibility in SharePoint 2013 by using JSON to collect data from just about anywhere is so much simpler of a model than using web connectors or other methods of grabbing data. If the server you need data from has a JSON capability, then it's just a simple matter of entering the request on a URL line, piping that into a data dictionary in SharePoint 2013, then parsing for the data you need. Very simple model, and fairly fast. If you have someone around to show you JSON then you may want to see how it works. With SharePoint in the cloud, the HTML 5 standard is allowing us to build entry forms that are flexible and look good on all devices. Unlike InfoPath forms, the HTML 5 forms flow and adjust to screen size. I believe that InfoPath forms will be around for at least 3 to 5 years but eventually it will go away because of the view capability on all devices of HTML 5. The reason InfoPath will stick around for a bit is because many clients still want their online form to look like a paper form. That mentality will eventually give way to forms that re-format to fit on all devices. If you're a SharePoint designer/admin, we're in a shift in the field which is going to bring a different kind of thinking on how forms are used with SharePoint and other applications. One part of that is with HTML 5 forms, because they will be usable on phones, tablets and computer monitors the optimization of the form is critical - simply, ask as little as possible to get the information needed and job done. This in itself will speed up processes which will be an advantage to business that adopt the newer technology. It's certainly a good time to be in the IT field.  
Comment posted by Kirk on Thursday, July 24, 2014 5:20 AM
[Todd] Oh yeah! Add a dash of client-side technologies to the mix and have a good time!
Comment posted by Todd Crenshaw on Monday, July 28, 2014 2:54 PM
Hey Kirk, you would have gotten a kick out of what some consultants we had do for us as far as client-side technology. We had map data that was rendering on employees laptops. The operation took upwards of 2 minutes to display. The laptops were about to die and the massive amount of data that was transferring (sometimes via cellular link) took forever to complete. Client-side is ok, but our consultants thought everyone was on giga-bit in the home office - doh! Just goes to show, you have to know what/who you're building sites and applications for!