Today’s tip is about the DEFAULT and SET instruction models. Both of these models will allow you to specify that a variable has a certain value, but in different circumstances and with different results. This article provides the basics on when and how.
To quote the HotDocs help file, “This instruction (DEFAULT) suggests a value for a variable if the variable is unanswered”. Unsurprisingly, the instruction is exactly what it appears to be – a DEFAULT value. It will not, in any circumstance, overwrite any existing variable value, even if that variable value is a single space character, or 0 in a number variable.
Personally, I find DEFAULT useful for exactly that – providing default or “starting” answers to variables that may be overlooked by users. Typically, its something I use with “fresh” answer sets, at the start of a matter. The simple rule is to generally not bother with DEFAULT, unless you’re using it in a scenario where the dialog isn’t (or shouldn’t) have (m)any values in it.
SET however, is a completely different kettle of fish. I use SET wherever I can. The way SET works is very simple – ask no questions, take no prisoners and absolutely give this variable the supplied value. It will override anything that previously existed in that variable. There is one major drawback to SET – if you use it in a dialog script, it will prohibit the user from changing the SET variable. Even if you wrap it in a conditional statement, there is no guarantee that HotDocs will re-process the condition properly and allow you to edit the variable. A minor bugbear. The workaround (if absolutely necessary) is to use SET instructions in a button (dialog element, script link) on your dialog. Because the SET instruction is not run by the script dynamically, but rather, is being run ONCE only on user click, HotDocs will not gray out the variable and prohibit changes. For the price of one click, you can set/clear/change/populate and manipulate your data as much as you want, without worrying about grayed out variables, or processing times (heavy script leads to slow response times. heavy script on buttons only results in a one-off hit when a user actually clicks the button. Its far more elegant).
And yes, I ignore all the HotDocs “errors” that tell me I am asking a variable in an interview and SETting it to have a value. Why do I do this? Because I presume that good code gets you a correct answer, but relying on a user to get it right can get you inconsistent answers. Lets say that everytime you specify you’re wearing a red shirt/blouse, you want black pants. If you’re male, you also want a red and white tie. If you’re female, you want ruby earings. Without SET, you are relying on a user to know the ensemble and, just as importantly, to key it in correctly, every time. Mistakes happen. Interruptions occur. And sometimes, people just plain get it wrong; its a part of the human condition.
I rely on human correctness (or, more accurately, avoid human error) as often as possible. So lets show how SET can be used to automatically calculate answers based upon user data entry. Here’s what my dialog script may look like:
//hide what we're going to force anyway.
HIDE Pants MC
HIDE Tie MC
HIDE Earings MC
//force the user to answer enough questions to calculate the answers
REQUIRE Gender MC
REQUIRE Blouse MC
IF Blouse MC = "Red"
SET Pants MC TO "Black"
IF Gender MC = "Male"
SET Tie MC TO "Black and White"
ELSE IF Gender MC = "Female"
SET Earings MC TO "Ruby"
END IF
ELSE IF Blouse MC = "Black"
SET Pants MC TO "Black"
IF Gender MC = "Male"
SET Tie MC TO "White"
ELSE IF Gender MC = "Female"
SET Earings MC TO "Diamond"
END IF
ELSE
//its not a red shirt/blouse and its not black either, let the user pick these ones....
//of course, you could specify as many ensembles as you wished.
SHOW Pants MC
IF Gender MC = "Male"
SHOW Tie MC
ELSE IF Gender MC = "Female"
SHOW Earings MC
END IF
END IF
In the above instance, you may be a little colour challenged, so you’d add this at the top of your code:
DEFAULT Blouse MC TO "Black"
This would thereby ensure that the first time you were presented with the dialog (for each different answer file), you could have your black ensemble, without touching a thing – just let the answers ride. At the point you specified anything in the Blouse MC variable, the DEFAULT instruction would be ignored forever more. But the first time round – it would do the job.
Looking at this, its a lot of code to avoid having the user answer a few extra questions. However, lets put this in perspective – let’s say this WAS a program to get dressed in the morning, and it would get you ready for work in half the time you currently spend. But a wrong answer would mean that you would have to go back to the start, re-specify your answers and let the program do its thing again. Suddenly, this isn’t “too much code”, but rather “time saving code”, because it calculates 2 answers based upon the answer to the first one.
The real benefit to such an approach (where possible) is that suddenly, your proof reading times are reduced. Sure, saving your support staff time (and improving data integrity) is great. But saving an attorney an extra few minutes on proof reading (because the attorney only has to check one answer, not three…), now that’s profitable.
Calculate data from existing answers where you can. The LESS questions you ask, the better; so long as your answers allow you to calculate everything you need to know. It is not uncommon for me to ask 10 questions and produce 13 answers. SET and DEFAULT will allow you to do this. DEFAULT will set up your most common answer set, so they don’t have to worry about doing anything at least SOME of the time. SET will allow you to implement “sets” of instructions, so that one answer produces multiple correct answers. That saves everyone time.
