Adding Spacing to Dialog Elements

When working with Dialog Elements, particularly Horizontal Lines, you may wish to add a line (or vertical space) before the dialog element.  You COULD add a separate dialog element for the spacing. But that adds to your scripting and dialog management.  Instead, you should add a <.pm> Code before and after the Prompt for the Dialog Element.

  • Create the Dialog Element
  • Set to Horizontal Line
  • Choose Alignment:  Left/Center/Right
  • In the Prompt, Right-click and add a Paragraph Marker
  • Type your prompt
  • At the end, Right-click and add another Paragraph Marker

Optional, you can add formatting around the prompt to control things like Bold and Italics.

Convert Time Matters Date to a HotDocs Date

Dates in Time Matters display as Dates on the Matter form. But, they are actually stored as Numbers. When you bring them into HotDocs via the Database Connection or Active Integration, you get a number, and not a date. This solution is courtesy of Bart Earle.  Dates are stored as the number of Days from December 28, 1800. The solution is to create a computation that takes that number and converts it into a date that can be used and formatted by HotDocs.

Create a compuation variable such as Convert Date CO. The formula gets the number of days from December 28, 1800 and subtracts that from the number from the TM database.

TODAY + (TMBaseDateNU – (DAYS FROM (DATE OF(28,12,1800),TODAY))) DAYS

The result will be negative if TMBaseDateNU references a date in the past. It then adds that result to TODAY, in effect counting backward or forward from TODAY to figure out the date.

Filtered ADDing to MC Variables

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
IF Testing TE CONTAINS “«Party Name CO»”
//do nothing
ADD “«Party Name CO»” TO Guarantor Select MC
SET Testing TE TO Testing TE + “ «Party Name CO»”

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).

QC Techniques for HotDocs

Some thoughts you might consider in providing QC for your templates.

Test, test, test … That is is the only way to fully debug your templates.  There is no replacement for having someone else test your templates.  Be sure to have your testers send you their comments and their answer files.  For this purpose we have set up a private board for posting comments and issues (

Once you have the answer file, run the assembly and spot the issues.  Keep reassembling until all the issues are resolved.  Use Word Comments and the Reviewer toolbar to add comments and then navigate through them.

In HotDocs, you can test portions of the template.  Just highlight (select) the port of the template you want to test, and then click on the Test button on the HotDocs Toolbar.

Off-Label Uses of HotDocs

Just for fun, I have included some interesting off-label uses of HotDocs.

Related Link: Litigation Support for Time Matters

Most of the time, we use HotDocs for the boring on-label uses to generate legal and business documents.  However, on some occasions we have been called on to do something fun:

Santa’s Workshop – Built a fictional application to manage contracting and job assignments for the North Pole.  We then featured the application on Holiday greeting cards.

Litigation Support – Document Profiling. Wrote an application to allow you to build and categorize a document production. Using dynamic list building features, every time a name is mentioned in a document profile it gets added to a master list that populated the To, From, CC, and Mention listings.  Client didn’t want to spring for a LitSupport system, but already had HotDocs.  A better solution is our Litigation Support plugin for Time Matters

HTML Tip Generator – Use of HotDocs to pull data from Time Matters Custom Form and to generate HTML Page with dynamic javascript for Tips on how to use HotDocs.  See the results at

Licensing Negotiation Workshop – CLE – Use of HotDocs to generate a term sheet after a two-hour staged negotation.  Instead of using Powerpoint to illustrate the points, we used HotDocs.

Interview Computations (Best Practices)

A few recent posters to the HotDocs list have suggested it was not “best practices” to use computation in the INTERVIEW computation; that is was best to use a series of ASK statements, surrounded by IF EXPRESSIONS to guide the interview. This Blog add looks into Best Practices for creating a document-scope INTERVIEW computation in HotDocs

Related Link: General information on HotDocs

A few recent posters have suggested it was not “best practices” to use computation in the INTERVIEW computation; that is was best to use a series of ASK statements, surrounded by IF EXPRESSIONS to guide the interview.

Best practices are always best understood in context:  what is the purpose of the practice; when is this practice appropriate.  In the case of using computations inside the INTERVIEW computation, there are a number of competing factors that affect your choice.

READABILITY: The purpose of the interview computation is to define the scope of the INTERVIEW for a document.  To this end, it is meant for a sequence of ASK statements.  The more you can focus on what is being asked, and place it on the dialog, the easier it will be to debug scripting issues arising from “misplaced dialogs” and “orphan variables”.  There may also be a benefit for those using HotDocs Online, where it is indeed best practices to explicitly state the order of dialogs asked.

SPEED OF PROCESSING: There are times where HotDocs processes or calculates certain scripts FASTER than other ways, used by more experienced developers.  I have found a modular master interview, with optional calls out to computation variables that contain the dialog asking sequence to actually run faster.  In a Master Will, I might have a sequence dealing with pre-residuary gifts that I would isolate from the main interview in its own computation.

DATA-MANIPULATION: HotDocs 6 and HotDocs 2005 fundamentally changed the way HotDocs processes data.  It changed from a “linear processing” to “recursive processing” whereby each new data entry leads to a recalculation of the complete interview tree. Being aware of this has led to certain best practices on our part, namely using either (1) Buttons that launch computations or (2) computation scripts in the main interview that contain “flags” to determine whether or not they have been launched.

MASTER CMP vs. DISTRIBUTED CMP: also known as MATTER SCOPE INTERVIEW vs. DOCUMENT SCOPE INTERVIEW:  I am a big believe of Matter Scope Interviews; a single CMP file that launches a master interview that start out with a Document Selection dialog, and then renders a custom interview based on the document(s) selected.  In such an environment, interview scriptlets (or subinterview computations) are critical.  On the otherhand, if you are only doing document scope interviews, which work in a system with shared matter-scope answer file, it would be easier to keep the scripting to simple ask statements in the INTERVIEW file.

Tips for Working with the HotDocs Markup Tool

In working on the CIC exam for HotDocs, I took the opportunity to master the HotDocs Markup Tool and HotDocs Template Generator.  In this article, I examine some tips on how to use the tool to the best advantage.

HotDocs has recently released the HotDocs Markup Tool.  A few of you may have dismissed it as a toy … real coders don’t need markup tools.  But I took the challenge to see if I could find a use for the tool.  Following the NYMetro user’s group where Marshall demonstrated the tool, I started seeing additional features, not obvious on the surface that have been built into the tool.

Now, I am a big believer in planning.  I build spreadsheets for complete template systems.  I layout all the fields, organize by topic and series and name consistently.  The concept of a markup tool, therefore is appealing, but only if I can have my categories and groupings.

Conclusions about the Tool

There are limitations to the tool, but on balance, its ability to write directly to a HotDocs component file and to interpret directly IF expressions and variables with formatting, promise the potential of much faster template development.  Doing work faster and more efficiently means projects get done.  There is a value to finishing, as a significant number of HotDocs systems never get finished.

So … if you are going to use the tool, here are some tips

  • Code: This is the markup that will actually show up in the document.  Use abbreviations that group the variables by target dialog and then identify the type of variable.  Do not try to get the exact HotDocs variable name.  Use something descriptive.
  • Variable Name:  Take some time to think out the variable name.  Realize, this is a database, so you can change the variable name BEFORE you publish it into a component file.  Give it your best shot.  Use a prefix that groups the variable by the target dialog.  Use a suffix that identifies the data type.
  • Type:  This is merely a matter of telling which type of component to create.  There is now support for Multiple choice variables.  Also, note the support for computation variables.  This does not mean you can actually create the computation, but you can place a computed variable in the template and it will create a blank computation that you will later use.
  • Default:  This is the format example.  It is worthwhile setting this, particularly for dates and numbers.
  • Options:  This applies only to Multiple Choice variables.  There is support for setting both the options and the prompts
  • Resources:  This is a fancy name for Help Text.  For some reason, HotDocs persists in calling this “resources” when it is really just links for help text. At the moment, the only support is for the standard help text, not for links and URLs
  • Notes:  Very useful for notes and status.  Not sure where these end up in the component file.

Now what can be done with the data?

  • Drag and Drop:  You can drag and drop from the list into a template.  It uses square bracket notation for the variables
  • Add Logic:  The square bracket notation can also read IF expressions and Repeats and End Repeats, End Ifs etc and translates them into chevron notation.  It is not clear whether the if expressions can use the pseudo variables in the markup and replace them with the actual variables or whether you have to use the HotDocs Variable.
  • Copy All Rows to Clipboard:  This lets you copy the complete database to the windows clipboard.  You can then “paste” it into a spreadsheet.
  • Paste Rows from Clipbard:  Assuming your clipboard matches the columns on the spreadsheet, you can now copy from Excel into your markup database, effectively creating a data dictionary that you can supply to your authors for template markup.

Dealing with Irrelevant Answered Variables in HotDocs

Irrelevant answered variables in HotDocs can have their consequence.  This blog notes the problem, its consequences and some solutions.

HotDocs is very friendly, as programs go, in dealing with “unanswered” data.  HotDocs gives you the option, if it doesn’t have sufficient data to fill in a variable or figure out an IF Expression, to display (1) Nothing, (2) A line, (3) [Variable Name] or (4) *** Variable Name ***.  This friendliness, has some consequences.

As recently posted on the HotDocs list, one consequence is that if a field “is answered” and stored in the answer file, but not relevant to a particular set of interview choices, that answer will still be used in the assembly.  The result will be that “irrelevant client data” will show up in the document.

The solution to this problem is to properly nest variables and conditions.  This is not as easy as it seems.  In a complex template, the web of dependencies and conditions can be difficult to track down.  Good dialog scripting and organization can help, but it can take some time to hunt down the proper conditions.  More often, you can over conditionalize a variable, and whole sections that should be relevant will not come in.  Because the “interview script” and the “template” are independent objects in the assembly system, both have to be separately validated and scripted.