InfoPath, Microsoft Strikes Back!
It’s been a while since I have posted. It has been very hectic. I am slap dab in the middle of a project and it is kicking my butt. For simplicity purposes I am developing an InfoPath (IP) form for what could be used as a billing system. Although IP could not do this alone it is much easy to develop the UI in IP then to try and replicate its functionality in .NET.
Initially I started out with one single form, but the deeper into the rabbit hole I went the less IP was compliant. My Secondary Data Sources were simple SharePoint (SP) lists. The Sr. Developer dropped some code into SP so any data entered on a list in that site would automagically be updated in a SQL Database. The reason for this was to speed up the data feeds to the IP form. By storing supporting list and the IP form as an XML blob in the db we could write Stored Procedures and pass parameters, thus allowing data filtration before it gets to the form.
Now on the eighth iteration of this form and I’m still struggling a bit with what IP will allow me to do and what needs a bigger hammer to make it work. Several releases prior I went to IP template parts (TP). I chose this path now because I have learned more about the project. Eventually I will roll out many forms which will be variations of the main one. I will be setting them up as templates with prepopulated data. The total number of needed forms is unknown at this time, but I am expecting about 32. Playing with the TPs I figured make one change, and update all, right? Wrong. Well for the most part this is fairly true. Here are some issues I ran into.
When you change or create a TP it has to be added to IP as a control. As an updated TP you have an option to update form with the new TP. This means every form has to be opened to make the update. Most of the time this will be fairly simple except under these conditions
- Adding a new field to the TP
- Resource files
- Button Control IDs
- Default values, Rules across TPs (If multiple TP exist on one form)
Let’s start with adding a new field. I did not figure this out right away. It took several modifications to understand when this issue occurred. I found after updating a form with a modified TP the UI of the form looked unchanged (except for the modifications), but when you looked at the schema (field structure) it added a replication of the original node and in addition prefixed all field, group and section nodes in the TP with a “_1″, “_2″ etc…. In the figure you will see to nodes, myLineItems and myLineItems_1.
Maybe this is not critical sometimes, but for this project we are depending on the XPATH for every field. If this changes the code on the back end will break. I struggled a bit with this trying to figure out why this happened only sometimes. So I started noting every step each time I updated the TP and began comparing differences. I found when I added a new field to the TP upon update in the form it would create a new replicated section. Now that I found the culprit I needed to find a solution to prevent this. For now it is nothing fancy. I found If I deleted the part and the field nodes from the form, saved the form and closed it, upon reopen I could add the updated TP and keep my original names for all the fields, groups and sections. I’m not sure why Microsoft would build functionality like this. If I copy a file in windows I get an alert to over write or rename. Why not build this into the TPs, giving the user the choice to over write or create with new name?
Moving on to the Resource Files and how Microsoft strikes again. In the attempt to save time when updating TPs I started adding Resource files to the TPs. This way when updated I would not have to re-add or attach them. For XML files it is not such a big deal, but images used in Picture Buttons is a nightmare. Microsoft decided to replicate these also. So a form with several TPs and several Picture Buttons could end up with 15-20 resource files once the TPs are imported into a form. I do have to give them some credit for the data connections. At least these do not replicate, but are renamed with the TP name at the end. No matter how many times it is updated it will keep that name even when you rename it in the main form. So why can’t we have a similar functionality throughout the form? Now each iteration I roll out I find myself going into the resource files and deleting the duplicates, then updating all the picture buttons and renaming the Control ID’s.
So if I create a button, picture or not, in a TP and add it to a form with a specific name, why on updated does Microsoft give it a default Control ID in the main form? If you are running code off the button click event, once it is renamed the function doesn’t fire. Now I have to go back and touch every button and rename the ID to match the form code. I know what you’re thinking; why not name it in the TP before updating. Yes, I already did this and it does not retain this name. Another major fail!
My final complaint is focused on the maintenance of default values and rules across TPs. I created a multiple select for day of the week using a repeating table. Without going into any major details I set 7 default values one for each day of the week and in the header a checkbox to select/unselect all. By default you can see the first default value. A typo on my part added “Sat” first instead of “Sun”. No matter how many time I have changed this, updated, in the TP or deleted the TP from the form it will not update in my final product. I am forced to go into the main form and make this change there. Again for the most part the rules stay intact, but when Microsoft forces me to delete the existence of the TP because it wants to rename it I lose all the rules I have had setup. Not knowing this can be frustrating when published an administrator approved template, launching the form and nothing works.
This process of elimination took many hours or pulling my hair out. Although some of this stuff may sound obvious when you’re in the fox hole we can sometimes over complicate what we are doing, putting more into it than what we really need to. I am hopeful Microsoft can fix some of these issues on the next release of IP, but I am sure that version will have its issues for us to find and deal with.
