While <<*Ask*>> commands discussed above may constitute the bulk of your Interviews, it likely will be the <<*If*>> equation that will form the backbone of the document automation process. It is the <<*If*>> equation that lets you declare comparisons and to set up your decision and branching points.
Let's say you are drafting a document that has optional text dealing with children. You want the text to be kept in the document when there are children and discarded when there are none. Let's further say that the document contains other language that you want to keep when there are minor children, but which should be discarded where there are no minors to provide for.
Using <<*AskOptional*>> commands, you might ask the question "Are there children?". If (but only if) that question is answered "Yes", you might then ask "Are there minor children?". (Of course, if there were no children, there couldn't be any minor children. Therefore the question should not be asked..)
Here is the way this sequence might appear:
<<*AskOptional*!children!Are there children?*>>
<<*If*!children!="Yes",<<*AskOptional*!minors!Are there minor children*>>,!minors!="False">>
NOTE: The values "Yes", "True" and "1" are functional equivalents. The above could have been written:
<<*AskOptional*!children!Are there children?*>>
<<*If*!children!="True",<<*AskOptional*!minors!Are there minor children*>>,!minors!="False">>
Let's study the structure.
1. Note first that a !groupname! (in this case !children!) is used. As with other !group!, the name ties the various elements of the document together.
2. Now note the classic three-part "if . . . then" programming structure in line 2:
"If Condition, (If 'True' Action), (If 'False' Action)"
This three-part logic structure is practically universal. Simple commas are used to separate the three elements.
As applied to the example, the user first encounters the initial (Children) question. The user provides either a "True" or "False" (or 'Yes' or 'No') answer. The "If" command is encountered immediately after. Pathagoras 'measures' the value of the !Children! group, and responds accordingly. If !Children! was answered "Yes" (by checking the check-box), Pathagoras presents the prompt that appears between the first comma and the second comma. If Pathagoras sees that !Children! was not answered "Yes", it processes the information that follows the second comma. This 'logic' follows classic 'Boolean' logic, which 'reads': If (this) is true, then (do this), else (do this).
<<*If*!Children!="Yes",<<*AskOptional*!Minors!Are there minor children*>>,>>
See Bigger Example for more examples of the <<*If* . . .>> command.
Setting a True/False Value
Setting a 'True/False' value (<<*Optional* . . .>>):
<<*Optional* commands are processed based on simple 'true' and 'false' values of a !group!. And the group can be set via an <<*If* statement, and several examples above demonstatrat that. Here is a repeat of one:
<<*If*!Children!="Yes",<<*AskOptional*!Minors!Are there minor children*>>,!minors!="False">>
Repeats: If you need to assign a Repeat value of one GroupName to that of another, you can make that assignment with the !Group1!=!Group2! command. E.g.,
Depending upon the various assignments, if your client is the defendant, the number of repetitions of [Client Name] in the document will be equal to the number of Defendants selected at the top.
When your 'If' statements seem not to give the expected results, check these elements:
The sequence of the 'True' and 'False' portions
The sequence of a precedent Ask commands that sets the value of the 'If' comparator.
The proper spelling of the !GroupNames!.
Is the 'False' value of the statement set? See above for discussion.
1. The <<*If* . . .>> command, and it's various parts (the 'True' part and the 'False' part and its mandatory structural elements) is definitely 'programming language. Therefore, If's will be use only within the Ask table portion of a document where programming is allowed.
2. Pathagoras is programmed to stop at an <<*If* . . .>> command if the value it requires has not yet been set. Stated another way, if an Ask table contains an <<*If* . . .>> line for which the !groupname! has no value, Pathagoras will not proceed further. This happens when the precedent value is being asked in an immediately preceding <<*Ask*>>. Only when the precedent value is assigned will Pathagoras continue. You can also break processing until the !Groupname! is set using the <<*Break*>> command. (Caveat: If the <<*If* . . .>> line is comprised of multiple comparators (i.e. <<*If* this AND that . . >>, Pathagoras only checks for the existence of the first comparator. You should use <<*Break*>> when using multiple comparators in most cases.
3. When a number represents a position in a list, it is enclosed in quotes. When the number represents an actual ('hard') value (i.e., 5 means 5 pets in the above examples), it is not enclosed in quotes.
4. You can set multiple resulting values with the <<*If* . . .>> command. Simply separate each item with the pipe ('|') character. E.g.
<<*If*!Type of Deed!="2",!QuitClaim!="True"|!Warranty!="False",!QuitClaim="False"|!Warranty!="True">>
(The comma (in red) still separates the 'if true' and 'if false' parts of the master equation. The pipe tells Pathagoras to split the true and the false parts into multiple actions.
5. You can set multiple groupnames to the same value within the <<*If*>> command. List them within the same ! and ! boundaries. E.g.,
<<*If*!Type of Deed!="3",!Warranty!="True"|!Quit Claim,Special Warranty,No Warranty!="False",>>
5. The '<<*If command can accept the following arguments:
(any)--<<*If*(any)!*Type Of Deed!="1,3,4,6",!Title Search Done!="True",!Title Search Done!="False>>
(not)--<<If*(not)*!States!="1,7",!Continental Tour Only!="True",!Continental Tour Only!="False">>
See next page for more examples.
*If* logic can be tough stuff. If you are nesting equations, adding multiple comparators and augmenting the equations with arguments and lists of possibilities, it will take you some time to get it all right. There is no question that this is ''programming.' But this programming is always and clearly visible on the face of your document. Therefore, it is easy to edit, And with practice, it gets easier to read and explain. Don't get frustrated. Keep on trying. When testing, don't test on the entire document. Break out the relevant sections and put them in a new document for testing. When its working as expected, then move it back into your main document for 'full' testing.