The Language instruction allows you to design, code and assemble templates in HotDocs in a language other than English.  To be able to use this feature, you must first contact a Lexis Nexis sales representative to obtain a DLL for the language you wish to program with.  HotDocs has DLLs for the following languages:

ENG (English), DEU (German), DES (Swiss German), DEA (Austrian German), FRA (French), NLD (Dutch), ESN (Spanish), ITA (Italian)

Using any of the codes above, the instruction you place in your template is as simple as:

LANGUAGE FRA

Also with the Language instruction, it is possible to format the thousands and decimal separators.  The following instruction would use the Italian language, set the thousands separator to a period “.” and the decimal separator to a comma “,”.

LANGUAGE ., ITA

Not to be confused with the ASSEMBLE command (which queues a template for assembly after your current template has finished), the INSERT command does exactly that – inserts the content of one template into a different template (known as the “parent” template).

This instruction is extremely handy and very under utilised as it is useful for a wide variety of things, not just inserting letterhead!

The INSERT command should largely be used in templates.  There are ways to use the INSERT command inside a computation, but there are limitations and rules that apply.  Allegedly, an INSERT command cannot be placed inside headers or footers in your template however, we have found that it works just fine with footers, which can save some time in some situations.  At any rate, here’s how it works in several different ways –

Template in same location as the template you are inserting into (known as the “parent” template)
«INSERT “Template.rtf”»

Subfolder of location of parent template
«INSERT “SomeSubfolderTemplate01.rtf”»

Full file path for anywhere on your system
«INSERT “T:HDTemplatesLitigationTemplate01.rtf”»

Using a Reference path
«INSERT “^HotDocsLitigationTemplate01.rtf”»

Default Templates folder
«INSERT “Template01.rtf”»

The INSERT statement is quite often used inside IF statements to conditionally insert oeprative parts of documents.  Interstate notices, optional schedules, attached forms etc are all usually INSERTed inside IF statements.

Common Uses for INSERTed Templates

• All stationery, such as letterheads, faxes and memos, with accompanying headers, footers and page numbering
• Signing / execution clauses (say, a single “corporate execution” block and a single “power of attorney execution” block)
• Court headers and footers
• Boilerplate text such as acceptance clauses, court seals, hearing dates, witness blocks and the like
• RE lines on letters
• Schedules

Additionally, INSERTed templates are quite often used simply to segregate content in long templates, so that each template can be tested by itself in isolation to the rest of the template.

Some Off Label Uses

With a bit of effort, it is possible to set up INSERT templates to take parameters.  All you have to do is write your INSERT template with a temporary variable that you SET before you insert.  Here’s a quick example:

INSERT Template Code:

Some random text up here that is boiler plate and always appears regardless of how the INSERT template is used.

«IF OPT UseNotice TF = TRUE»
This notice must be complied with within 14 days unless otherwise specified.

«END IF»
More random text here about something or nothing at all really.

«IF tmpTE = "Borrower"»
This notice is directed to the Borrower's solicitors and must be complied with within 7 days of the date hereof.
«ELSE IF tmpTE = "Lender"»
This notice is directed to the Lender's solicitors and must be complied with whenever convenient to the Lender.
«END IF»

«IF OPT UseFooter TF = TRUE»
This footer is absolutely pointless except insofar as it demonstrates the concepts of parameters in INSERT templates as applied by the HotDocs document assembly engine.
«END IF»

So all we have really done here is code the INSERT template with some preset variables to hold preset values.  Then, when its time to insert the template, we set the parameter variables prior to inserting the template.

PARENT Template Code:

«SET tmpTE TO "Borrower"»«SET OPT UseNotice TF TO FALSE»«SET OPT UseFooter TF TO TRUE»
«INSERT "OurInsertedTemplate.rtf"»

The humble IF statement is the core of all logic in any programming language, HotDocs included.  IF statements don’t actually do anything but rather, they provide a structure within which other commands are executed.  To bring any intelligence to your document-producing systems, you must understand the IF, ELSE IF and ELSE statements, as they are used everywhere.

I’ll work with a computation for these examples, as it is simpler than the template version, as no chevrons are required.  Lets get some examples happening.  Lets say we have a variable named “Var TE” and Var TE has a value of “Bob”.

Example #1a – the basic IF statement

IF Var TE = "Bob"
"His name is Bob"
END IF
//this would produce "His name is Bob".

Example #1b – the basic IF statement

IF Var TE = "Joe"
"His name is Joe"
END IF
//this would produce an error

The above code produces an error because Var TE does not equal Joe (it’s still Bob) and there is no script in place to handle what happens if the variable isn’t equal to “Bob”.

So lets look at how to handle that with an ELSE statement.

Example #2 - IF and ELSE
IF Var TE = "Dave"
"His name is Dave"
ELSE
"His name is not Dave"
END IF
//this would produce "His name is not Dave".  In this example - we have some code to run if his name is "Dave", ELSE (readable as "if its anything else in the world..."), produce "His name is not Dave".

This still isn’t ideal.  What if we want to do something specific for Bob OR Dave, but something entirely different if it isn’t either of them?  Lets look at the ELSE IF statement.

Example #3 – IF, ELSE IF and ELSE

IF Var TE = "Dave"
"His name is Dave"
ELSE IF Var TE = "Bob"
"His name is Bob"
ELSE
"His name is not Bob, nor is it Dave"
END IF
//This would produce "His name is Bob". If we set Var TE to the value of "Mark", the result would have been "His name is not Bob, nor is it Dave"

The easiest way to read this stuff when you’re learning is as follows:

IF (Some specific condition is true)
//do something here, for this condition only
ELSE IF (Some other specific condition is true)
//do something different, for this condition only
ELSE (if its anything else in the whole wide world)
//do something different here if nothing previously is true
END IF (close the statement)

In english, it would read exactly as it is typed above – IF something is true, do something, else if something different is true, do something different for this condition only, else if its anything else in the whole wide world, do something here.  It gets tricky, but it is really just a series of “what if this is true” questions and results.

Some things to remember….

1) Every IF statement must have a matching END IF – they are a fixed pair with no exceptions!
2) ELSE and ELSE IF statements can only occur inside an IF/END IF pair.  They do not have matching END IFs themselves
3) Nested IF and END IF pairs must nest “inside” each other.  I’ll use bracketed numbers in place of conditions to demonstrate:

IF (1)
//do something

IF (2)
//do something here
ELSE
//do something different
END IF(2)

IF (3)
//do something different again
ELSE IF (3)
//do something weird
ELSE (3)
//do something really weird
END IF (3)

END IF(1)

As you can see, IF statements work from the inside out.  It is nearly always best practice to write your IF and END IF at the same time, then move your cursor back and complete the rest of the commands between the IF/END IF pair.  If you open an IF statement and immediately close it, you will not lose where you are up to with code and save yourself substantial time debugging problematic HotDocs code.

Please note: HotDocs will evaluate your IF statements from top to bottom.  In the above example, if IF statement #2 was true AND IF statement #3 was true, HotDocs would only produce #2 – because it will find a true If statement, produce the result and then jump straight to the END IF.  Bear this in mind when designing your code.

These four commands are essential in presenting user friendly and user-proof dialogs in HotDocs.  When designing systems, it is generally best practice to show only those variables that require (or may require) an answer and HIDE or GRAY those that are irrelevant.  HotDocs provides a rudimentary manner to handle this automatically, but if you are designing complex systems, you may need to use these four commands. All of these instructions are used in dialog scripts only.

Here are some examples that should be fairly self explanatory…

Instead of using a variable name, you can also substitute the “ALL” parameter….

When building a system to really lockdown data entry, you may wish to write a dialog script something like this to force entry of everything in the correct order…

All of these commands are dynamic as of HotDocs 6, which is a major step forward.  Whilst they may look like eye candy, these instructions serve to produce better and more accurate documents every time, simply by forcing/prohibiting better data entry.  When combined with REQUIRE, you really can obey the rule that “if a variable is visible, it must be answered and if it is invisible, it is irrelevant”.  When your systems can follow this rule, your users do not have to have any knowledge of what they are working with or understand the sometimes complex concepts behind the scenes – all they need to know is that if it CAN be answered, it SHOULD be answered and if it cannot be seen, don’t worry about it.

Another HotDocs instruction model that does exactly what it sounds like, FORMAT allows you to specify the formattin of a “list style” RESULT.  Rather than explain, I’ll simply provide 2 examples which demonstrates everything you’ll ever need to know about FORMAT.

Lets have a repeating dialog named “Party RPT” that has a single variable on it – PARTY Name TE.  Lets produce some differing results with FORMAT, presuming that we have 3 names in our list:

Example #1

Example #2

All it is doing is specifying the format in which a list style result is accumulated and represented.

The HotDocs instruction “FILTER” is one that I use in almost every system that I’ve designed.  Its purpose is exactly what it sounds like – to filter (a repeat), based upon a certain criteria, so that the data output from the repeat is reduced – only the repeats that match the filter come out.  Like most instructions, it is best explained by example.

Lets say we have a repeating dialog named “Party RPT” that collects information regarding, well, parties in our fictitious matter. A party can be a corporation or individual (PARTY Entity Type MC), but never both. Throughout our system, we are constantly required to insert a sequence of all party names, as well as a sequence of all corporation names.  While we COULD use REPEAT instructions in our templates, this will not work in repeating templates, nor repeating sections.  So lets use the filter command to meet our requirements AND simplify code (its much easier to pre-calculate such lists instead of coding them in every template!).

So lets do our “list of all parties” first – this would go in a computation…

That’s it – all done.  Very simple, and now GEN Parties All Names TE contains something like “Seth Rowland, Basha Systems LLC, Ian Burrows, Routine Automation Pty Ltd and John Doe”

Now, lets use our FILTER instruction to slim that list down to only the companies.  Here is our filter computation, named “fil Party Companies CO”

PARTY Entity Type MC = “Corporation”

That’s it – a straight forward test: is the party entity type a corporation? yes/no.  So lets use this, again in a computation…

Filters are absolutely fantastic, as they allow you to eliminate a lot of repetitive code and variables.  Take a litigation system for example, with Plaintiffs, Defendants, Third Parties, Plaintiffs by Counterclaim, Defendants by Counterclaim.  You COULD have a separate repeat for each of these parties.  Alternatively, you could have a repeat for Plaintiffs, with a checkbox to indicate that they are also optionally a defendant by counterclaim – then use filters on this variable.  Taking it one step further, you could simply have a dialog Parties that contains ALL parties in the matter, then use multiple-choice, multiple select variables to specify all the roles that a given party may have.  Another example is real estate documents – a given party may be a borrower, but optionally a mortgagee.  If it is an investment property, they may also be a lessor/landlord.  Occassionally, they may ALSO be a caveatee.

Filters allow you to collect information once centrally and then filter it in various ways to produce exact results.

The ERASE instruction is one of the handier instructions in HotDocs if you are populating data dynamically more than once, or are using ‘temporary dialogs’ during your interviews.  Use of this instruction will completely erase the contents of a variable or dialog, but be warned: it will erase all iterations of that variable or dialog!

Let’s say we’re doing an Estate Planning matter – you have the client, their spouse, a list of children, trustees, executors and some random beneficiaries.  There’s a lot of entities in there.  If you’re working with a system by Basha Systems, there would likely be a central party list that functions as a contact database.  If you’re not, you have several repeats containing contact information.  Either way, the approach is the same.  The example I will use is a generic letter.  You want to program a generic free-style letter that can be sent to any entity on the matter.  But because you quite often wish to send letters to the same party consecutively (a few days apart), you want the generic letter dialog to retain the information of who a letter was last sent to.  Here’s how you do it.

Create your dialog as you ordinarily would – name, address, salutation etc – lets call our dialog Generic Letter DLG.  I won’t get into the import mechanics – all we’re showing here is the ability to clear an entire dialog easily.  On that dialog, we’ll create a button that points to the computation Generic Letter Clear CO.  The script of that is:

ERASE Generic Letter DLG

That’s it.  If the variables on the dialog are saved in the answer file, then the next time you hit that dialog, the details of your last generic letter appear.  If the user wants to use those details – great!  If they don’t, they simply click the button and everything on that dialog is erased and the user can pick a new entity to direct a letter to.  Be warned that you don’t use this on repeating dialogs, as it will erase the entire dialog and all of its iterations/repetitions.

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.