Quite often, you’ll want to dynamically create the options of a multiple choice variable from a repeating dialog (or other source). This HotDocs snippet will detail how you can do that. The concept is simple – if you ADD an option to the MC variable, you also accumulate the ADDed value in a text string, so that you can test against that string later. Then, each iteration, you test whether the current value you may wish to add already exists in the text string and if it does, you do NOT ADD it. If it does NOT exist, you ADD it to the MC variable, and also to the text string.
In this example, we are repeating through a list of generic party names (essentially a database on the fly in HotDocs, using a REPEAT dialog), and adding names to a multiple choice variable for possible Guarantors. Testing TE is the text variable that will store each unique value as it is ADDed to the multiple choice variable. Party Name CO is a computation that assembles the full name of a given party, much like you’d see anywhere else in a HotDocs system. On this note – it is quite often easier to build a computation specifically to use in this scenario, so that you can do all your error checking & string building there, leaving your ADD instructions simple and clean (even if you are only joining two unconditional vars together, it LOOKS cleaner). Guarantor Select MC is the multiple choice variable that we are building on the fly.
//clear & clean our values
CLEAR Guarantor Select MC
SET Testing TE TO “”
//lets go
REPEAT Party RPT
IF Testing TE CONTAINS “«Party Name CO»”
//do nothing
ELSE
ADD “«Party Name CO»” TO Guarantor Select MC
SET Testing TE TO Testing TE + “ «Party Name CO»”
END IF
END REPEAT
You could also use a HotDocs Filter to do this however, this approach is “safer” for one reason…as soon as you filter a repeated dialog in HotDocs, the system var counter is altered. If I wanted to use my new multiple choice variable as a lookup to Party RPT in this example, my ADD line would look something like this:
ADD “«COUNTER:009»|«Party Name CO»” TO Guarantor Select MC
This would mean that the option is the COUNTER value (meaning index) of the dialog that it came from, while the prompt is the party’s name. If you are using filter, and the filter actually strips out an iteration from Party RPT, the COUNTER will be WRONG. Yes, wrong! No, this is not a bug in HotDocs, it is intentional as COUNTER with a FILTERed dialog will reflect the filtered answers rather than the “complete” answers. To explain a little more clearly, lets take a look at a repeating dialog answer set that contains a duplicate entry:
1 Jack Jones
2 John James
3 Jack Jones
4 Michael Davis
Using filters and the above ADD code, you would get a list that looks like this:
(1) Jack Jones
(2) John James
(3) Michael Davis
Michael’s index in Party RPT is actually 4, but because the 2nd occurrence of Jack Jones got stripped out, HotDocs changed his COUNTER value to 3 (because this is his index in the FILTERed answer set). This means you cannot use your MC variable to index Party RPT later, because Michael’s entry will actually index incorrectly. If however we use IF statements instead of a FILTER, we would get:
(1) Jack Jones
(2) John James
(4) Michael Davis
No filters means that COUNTER is once again a reliable indexing tool. This minor difference may not make any difference to many HotDocs developers out there. But if you are populating dynamic lists and starting to toss around (or centralize!) data, be aware – FILTERing repeats can be problematic. The rule is simple: if you intend to use a COUNTER in your ADD statement, dont use filters. If you must use filters, you must use a manual COUNTER that you define, control & increment yourself. Bear in mind that this can lead to endless loops and irritating code, so I try to avoid it where possible (which I get away with most of the time).
