InfoPathology - Part 5 - Win Forms & Popup Message Boxes

Win Forms

Although it is certainly not obvious, you can build an entire Windows application on top of an InfoPath form. Add you have to do is add a reference to System.Windows.Forms to your InfoPath code project. This allows you to do two main things. First, since InfoPath gives you almost no programmatic access to properties of its controls, you can pop up a Win form with a supped-up UI or a custom user control to overcome this lacking in functionality.

For example, I created a tiny application that I called the “User QuickSelect.” In an older version of the system I was working on, there was a piece of logic that looped through the entire user database, and built a dropdown of over five thousand names. And the client hated it. On top of that, the InfoPath dropdown list control is not very fun to work with.

So for the User QuickSelect, I built the drop down of names, but then added the functionality so that the user can also type in a name. With each character entered, the control would “finish” the name with best possible match, and fill the drop down list with the rest of the possible names. InfoPath’s dropdown list certainly can’t do this. And by popping it up in a Windows form, I gave myself time to load the data on the fly.

The other benefit of using Win Forms is the ability to improve the user experience. Although InfoPath goes quite far here with “XP-ish” features, such as textboxes lighting up when you hover over them, repeating controls that allow dynamically inserted rows, and allowing the user to toggle the visibility of hidden sections, there are missing elements that are, by comparison, fairly intrinsic to Win Forms.

The first thing that comes to mind here is progress bars. Whenever the user opens up a form that takes a while to download, or calls a complex, time-consuming web service, they will be staring at an hour glass for a few seconds, if not longer. So what I do is first pop up a Windows form that has nothing more than some text in a label and progress bar. Then, using a fully functional multithreaded mechanism, I will advance the progress bar as the form loads or the web service cranks.

So, even though the operation takes just as long, (or, indeed, longer as more resources are required to draw the form and handle the threads) the perceived time is shorter to the user, since they have something moving in from of them. This will have a positive affect on the overall user experience.

This is a perfect example of using code behind to plug the holes in InfoPath. If you wanted, you could load a tiny, blank form that does nothing more than spawn an entire Windows application; InfoPath would be nothing but a deployment vessel. But to be as efficient as possible, first push InfoPath’s UI as far as it would go, then drop in Windows forms elements when what you need to do simply can’t otherwise be done.

Popup Message Boxes

This suppimnt to the Win Forms posting is simply here to appease the perfectionist in me. The message boxes that you can pop up using InfoPath rules are ugly. You have no control over the size, icon, or even text alignment of the message. Whenever you need to use one, add a System.Windows.Forms reference to your project, and use the Windows message box instead.

Now you can set the icon, and be assured that the message box window will resize itself to fit the length of your text. This also gives you some added functionality. For example, you can popup a Yes/No/Cancel message box, and have its dialog result redirect form logic. This goes far beyond what the standard InfoPath message box can do.

Now, if you really, really don't want to do this, especially for non-managed code forms, you can always explore the XDocument.UI.Alert() method. This gives you some options to set the dimensions of the window and so on, but it still doesn't give you the control that a true MessageBox will.