Skip to content

September 24, 2007

Article: Coding Options for Building InfoPath Forms

Decisions, decisions. How do you add code to your InfoPath forms or decide whether putting code in them is even necessary? Learn the basics to decide what’s right for your forms.

When you want to build a simple form—something with a set of fields and perhaps a table of repeating fields—it’s easy to pick up InfoPath and bang out a form in a matter of minutes, or at least within an hour. However, integrating code with your InfoPath forms can make form building a trickier proposition. Sure, VB.NET and C# are supported languages for extending InfoPath forms, but how does that support work and how are you going to be able to deploy it?

This discussion will allow you to investigate options for developing code when using InfoPath, consider the limitations, and discover ways to make intelligent, code-enabled InfoPath forms.
A Cornucopia of Coding Options
At first glance your options for developing code with InfoPath look simple. You can use either script or .NET code, namely C# or VB.NET, but in addition to language choices there are two different approaches that you can take for .NET development. You can use either Visual Studio Tools for Applications (VSTA) or Visual Studio Tools for Office (VSTO). VSTA ships with InfoPath and doesn’t require a Visual Studio license, but VSTO does. As you explore the coding options for InfoPath, consider these .NET development environments first.
http://www.devx.com/enterprise/Article/35469

SPFile.Item == null and SPFolder.Item == null

This post requires a bit of explanation.  In SharePoint Folders and Files are really special items – well, most of the time, but I’ll get to that in a moment.  Many of the typical kinds of things that you want to do have to be done with the item object – for instance if you want to manage security.  So I was writing a tool the other day that went through and fixed up security a bit.  (Sort of like the Windows NT+ command line utility CACLS.)

Something happened that didn’t initially make any sense.  When I did an SPFolder.Item I would sometimes get null back as the result.  That’s not suppose to happen – or so I thought.  If I have a folder in a document library it has a corresponding item.  If I have a file in that library it has a corresponding item … most of the time.

The problem comes in when there are files which are necessary for the operation of the list or library which are ghosted (or uncustomized, if you prefer).  You see when a library is created the forms for displaying and item, creating a new item, and editing an item are all provisioned too.  The result is that the document library (or list) has a Forms folder and in that forms folder are created at least those three files.

So when you’re happily traversing down through a structure it’s more than possible that you’re going to encounter SPFolder and SPFile objects that have no corresponding SPListItem.  They don’t have one because they’re not an item in the list.  They’re special files and folders added to support the operation of the list.

Of course, that may not stop you from doing a double take when the SPFolder.Item call returns null.

Recent Posts

Public Speaking