Diagnosing a corrupt form is one of the most difficult service calls our team on the Service Desk faces. Here's how to work through what can be a seriously trying experience.

During the Build

A form typically becomes corrupt through an Author's impatience while rushing through the build or quality control experience, especially when dealing with Lists and Conditions and only rarely with Fields. Corruption happens when a modification is built or inserted into an existing List or Condition that renders the program unable to solve the command because it is circular or refers to a non-existent variable. The program becomes confused and stalls mid-execution of the troubled List or Condition command. Without fully considering what just happened, the Author then clicks Refresh, or perhaps not, then makes some kind of an adjustment and tries again. Whatever error stalled the program it is now embedded in the code, probably invisible to the Check Form tool because it retained key parts of its original structure, in effect camouflaging its problem.

The only times we se this created by a User rather than Author is when the User becomes impatient with the forms runtime, manually stops processing, and saves the form (which wasn't a protected template to start with).

Too often this starts a merry-go-round circus of diagnosis and testing all the normal suspects, none of which are guilty.

Here is how to prevent the problem.

At every step of form development, when we are absolutely certain that the most recent change or addition works as it is intended, we save the draft as a Word Template, a DOTX, rather than as a document, DOCX. This simple step assures that we won't unintentionally over-write the previous, proven version with an unproven new version. Only when we make the intentional decision do we replace the proven version with a new proven version.

How to diagnose a possibly corrupt form.

The first step, as always, is to use the Check Form tool. Follow any leads that result.

Fortunately, our programs are trained to leave a clue behind in certain cases of corruption. The program may insert an asterisk (*) at the beginning of a failed List or Condition, at the exact location where the program's execution stopped. An asterisk is proof positive that a form is corrupt. Be careful not to spread the problem backward to previous safe versions!

Faced with an asterisked post-Fill command, our first try will be to copy the complete paragraph or other text surrounding the failure. In this case, copying slightly more is better than too little. Paste the material onto a new blank Word page. Also copy and paste the entire Questionnaire into the new page. Use the Check Form tool to verify that the form has become active and to eliminate any unneeded Questions. This new form is your test bed for diagnosis without the mental noise of working with the real form. Figure out what isn't right. Because the text you moved won't work because of the pre-existing failure, you'll probably need to recreate the troubled List or Condition. That's OK, build it above the failing text so that the piece you're working with will run before the old text stalls the program again.

Only if the transfer doesn't work, use the Reset command to revert the problematic form to pre-Filled condition, then follow the previous instructions to move it to a new page and work it.

When you've created a List or Condition that works correctly, open a copy of the earlier-saved DOTX (!) file, add or replace the section that you've rebuilt, and test. It should work fine. When convinced of your fix, save a new DOTX file to in effect create a backup, and use the new file to move on with you project. 

Divide and Conquer

In the most extreme circumstance, where you've been through the Diagnostic Portal and are convinced it is a corruption issue but just cannot find it, consider divide and conquer.

Divide and conquer takes time and patience so we only use it when there are no viable alternatives. Copy one-half of the form and paste it into a completely new blank document. Copy the entire Question & Answer Table and paste it in the new document (if a simple copy/paste effort doesn't work use the program's Save/Load Q&AT feature instead). Use the Check Form tool to identify the unnecessary Questions and remove them. With that, run the test form. If it fails, divide it in half (keeping careful track of the pieces). If the remainder fails, repeat until you've isolated the failure. If the first test passes replace the text with the second half of the original document, add and then slim down the Q&AT and proceed as outlined earlier.

Either way, now clean up your mess and you're set to go.