Mutually Exclusive CheckBoxes in InfoPath

This is a demonstration of how to create mutually exclusive check boxes using InfoPath 2007.

Below is a screen shot from an InfoPath design form.  It contains 3 fields that I want to be mutually exclusive: Yes, No, N/A.  I have named these fields fldYes, fldNo and fldNA.

Double click the “Yes” check box and the "Check Box Properties" Dialog Box appears.

Select the rules button and the “Rules” Dialog Box below appears.

Click the “Add” and the “Rule” Dialog Box appears.

Change the name to something user friendly for your purposes.  This action is called “When True.”

Select the “Set Condition” button. 

The “Condition” Dialog Box appears.

Select the value TRUE and click OK.

That pop up disappears and you are back to the Rule Dialog Box.

Select the “Add Action” button.

The Action Dialog Box pops up. 

Select “Set a field’s Value” from the drop down box.

Upon selection, it changes the interface to the Action Dialog.

In my example, I have named my fields fldYes, fldNo and fldNA.

Use the selection box to the right of the Field text box to select “fldNo” as the field to set.

Type in “0” without the quotes into the Value text box.  I have found 0 to be much more user-friendly than using FALSE when setting these values.  YMMV.

Click OK.

We have set up the rule that whenever the “Yes” box is checked, the “No” box is automatically unchecked (set to FALSE.)  We need to do the same steps no for the “N/A” check box.  Click “Add Action” and add it for the other check box now, this time selecting the fldNA as the field you want to set the value for.

When you are done, the “Rule” Dialog Box will look like this.

Click “OK” to close the “Rule” Dialog Box.

Now Click “OK” to close the “Rules” Dialog Box.

Now Click “OK” to close the “Check Box Properties” Dialog Box.

Now that we did this for fldYes, we need to do this for fldNo and fldNA, setting the other check boxes to "0" whenever the check box is checked.

It’s a lot of clicking to create these check box behaviors, but it’s a Vanilla solution without relying on writing C# on the back of the form.

InfoPath Best Practice - Form Versioning

Because ours is an environment that needed to operate where network connectivity in the field may not be available as our clinicians care for a patient, one of the best practices I found was to actually place a text line in the beginning and end of any form to identify the form.

Every form I publish has something similar to this:

Form Revision Date: 07/07/2011                         Form Revision: 1.5a

I know, it seems so simple!  How do we not realize these things until after a lesson learned? 

If I ever get a call from a clinician who is trying to submit data to our database and they are having problems, I ask them what version they are running. 

This has saved me a few hours of frustration, I am sure.  It's the first question I ask when a clinician calls as the interfaces seldom change at this point, but items behind the scenes may change.

It is possible if you want to go away from Vanilla here and use a record in a DB to check the version before they submit.

My practice is I have a parameter table for the database.

I have a record for each form in the database.  My records would look similar to something like this (Rec#, Form Name, Version) except I use a much friendlier name for the form in my database.

1             Form1                 2.1

2             Form2                 1.1

3             Form3                 1.2

Within the FormCode class of the Form (select Tools/Programming/Microsoft Visual Stduio Tools For Application) create a constant for the form.

const string vFormVersion = "2.0";

As you prepare to publish forms down the road, you need to update this as you go along for each release and have it match the record for your specific form in the database.

Within the InternalStartup() method, you can execute a method you write yourself to query your DB for this value and compare it to the constant within your published form.  If they do not match, you can let the user know via a MessageBox that they need to go get the latest form.

Sending this message when they start up the form is only useful though if they have connectivity. 

If they do not have connectivity in the field, it will allow them to still enter and save the data as an XML document until they try to submit and I stop them again with the error message.

The key that they have the latest form is communication.  It’s not that difficult to put an email out to the group that uses these forms.

And, yes, I know a website or a web page would be the ideal solution regarding not having to tell people to get the latest form, but you have to remember the lack of connectivity is a limitation. 

They need to access the interface offline for submission later as there are large areas in Southern Indiana and Central Kentucky that lack connectivity, thus why InfoPath has worked well for this process.

Working with InfoPath

The first question that someone might ask is, “Why use InfoPath when the .NET platform allows us to create real projects with web interfaces?”

It’s a valid question, so I have to give a little history here. 

I work for a hospice that covers 33 counties in Indiana and Kentucky.  Our mission is to provide end of life care for terminally ill patients.

We have clinicians (nurses, doctors, chaplains and social workers) that cover areas that do not often include MiFi service in Indiana and Kentucky that allow them to connect to our network, so I had to develop something that was easily distributed, allowed them to save their input easily and later submit their information once network connectivity had been established.

InfoPath also offered easy integration with SharePoint and when I arrived here, we already had a functioning interface for one of our key projects between InfoPath and SharePoint.  It is also important to consider that the CIO likes a very Vanilla solution to solve our problems.  The more Vanilla a solution is, the easier it is to upgrade a product down the road. 

Developing a solution in the .NET platform would always be available if the benefit was great enough to move away from the Vanilla solution to something a little more like Butter Pecan, but InfoPath, allowing the ease to build the forms and the connectivity to SQL, was his flavor of Vanilla.

I had a couple of small obstacles I encountered along the way and in some cases, I searched far and wide for answers and that search took a couple days. 

This blog is simply to document some of the lessons learned and some of the best practices I learned along the way for InfoPath and other technologies.