The HotDocs DEBUG instruction model is very simple, very powerful and very clear about its use.  DEBUG is used to…well, debug!  If you have templates or computations that are producing unexpected or incorrect output, using the DEBUG instruction may get you back on track just a little quicker.

There are two uses of DEBUG – in templates and in scripts (both Dialog scripts and computations).  Both uses have a very similar effect.

By placing a DEBUG instruction in your template or script, you tell HotDocs to display the Debugger screen.  With the debugger, you can manually step through a script or template while viewing extremely detailed information regarding each variable’s value.  You can add variables to watch lists, “step” the script (ie: manually tell HotDocs to progress the script line by line) and watch the variable values change with each step.  Using DEBUG, you can quickly identify what data is coming in/going out and what data is changing.  This will allow you to track down any errors quickly, as you can not only assess each computation or variable, but also the variable values that went into creating the problematic data.

Additionally, the Debugger contains a processing stack tab.  This is a sequential list of templates and components to be processed, in order.  It will also give you the reason as to WHY HotDocs has a particular item in the queue.

In the most general sense, the Debugger gives you a real look under the hood as to exacty how HotDocs is handling/treating your code.  This is invaluable if you simply cannot make your code produce the correct content.

A very brief HotDocs tip today – the CONCEAL and OMIT instruction models.  These two commands make working with HotDocs dialogs as answer sources a little cleaner and easier for users to work with.

In short, CONCEAL keeps a variable from showing in the “Select from Answer Source” dialog – it is simply hidden from the user, allowing for the more meaningful fields to be shown only.  OMIT does a similar thing, but hides a variable from the user in the “Edit Answer Source” dialog box – again, allowing only the meaningful fields to show to the user.

These two commands go hand in hand to pare down information that displays in dialog answer source manipulation.  Rather than trying to show an example, these two commands are best “tinkered” with on a case by case basis.  If you want to try something cool, try using dialog answer sources in a scenario where only ONE variable is not CONCEALed.  The variable still showing should be an identifier, such as a name or similar.  That way, a user will simply see a nice drop down to pick from and all the other data will ‘appear out of nowhere’ – just like magic!

This stuff is super simple and takes about 10 minutes to master.  Play around with dialog answer sources, CONCEAL and OMIT – it may actually be FUN.

Unfortunately, the CLEAR instruction model doesn’t really have any use on its own.  Its job is simple: to remove all the options and option prompts from the specified multiple choice (“MC”) variable.  That’s it.  When used in conjunction with the ADD instruction (which adds options & option prompts to a specified MC variable), you end up with a pair of commands that can dynamically build MC variables on the fly, based on whatever data you desire.

For the sake of this example, lets say we are drafting real estate documents.  We have BORROWERS RPT, which collects information on…well, borrowers!  We have BORRS Full Name CO which constructs the full name of each individual borrower (ie: can only be used inside the repeat).  Lastly, we have BORRS Guaranteed MS, which is a multi select MC variable which asks which borrowers have guarantors.  Here’s how we’d build our BORRS Guaranteed MS variable:

CLEAR BORRS Guaranteed MS
ASK NONE
REPEAT BORROWERS RPT
ADD "«BORRS Name Full CO»" TO BORRS Guaranteed MS
END REPEAT
ASK DEFAULT

That’s it.  We firstly clear the MC variable, then inside an ASK NONE/ASK DEFAULT pair, we add the full name of each borrower to the MC variable.  The user may now select borrower names from the MC variable for insertion into the template.  In conjunction with the list format applied to the variable, you can quickly and easily generate user-specified lists of any data from any repeat you have in your system.

There are far more uses for CLEAR/ADD, but this covers what we consider to be the most useful one.

One of the cooler instructions is the ASSEMBLE command, which allows you to queue up a template for assembly in HotDocs.  When it comes to assembling individual documents in packages/batches (as opposed to a template package in a single document output), assemble is the only way to fly.

The syntax is easy enough:

ASSEMBLE "FileName.ext"

The true power comes from being able to conditionalize the ASSEMBLY command, as well as apply command switches to the ASSEMBLE command.  Imagine that you are drafting a Will or similar document for a client.  You could have a multi-select multiple choice variable (WILL Docs Additional MS) that asks what additional documents you wish to draft after the will.  You could then have something like:

IF WILL Docs Additional MS = "Cover Letter"
ASSEMBLE "WillCoverLetter.rtf"
END IF

IF WILL Docs Additional MS = “Trust Deed”

IF ANSWERED ( WILL DEED Exec to Trustee TF ) AND WILL DEED Exec to Trustee TF

WILL POA Exec to Trustee Duplicator CO //duplicates data from executors in will to deed trustees – run before assembling
ASSEMBLE “POA.rtf /ni” //no interview – Trustees uses same Will executors!

ELSE

ASSEMBLE “DeedOfTrust.rtf” //use interview as the trustees are different

END IF
END IF

Between optional use of command line switches, and optional additions of templates to be assembled, the ASSEMBLE command offers a very flexible way to build packages of documents on the fly, based on interview choices.  Many times, this is far more flexible and easier to build than master templates that actually contains 10 or so templates inside it.  Certainly, where a firm wishes to individually profile each document in their DMS, ASSEMBLE is nearly always the right answer.

Final note: you can use the ASSEMBLE instruction directly in templates, inside or outside IF statements – it works the same way you would use INSERT, but with the difference of assembling a separate document, not an ‘in-line’ document.  For basic ASSEMBLE usage, this is fine.  But if you’re writing conditions around them, it is nearly always more elegant and easier to work with in a computation (and quicker for HotDocs to process!).