Adobe Captivate System Variables and User Variables

This article introduces and explains Captivate variables, including what they are, the different types of variables, how to insert them, name them, and use them to display information in an e-learning module at run-time. You need to have a good understanding of variables because they are essential components of many user interactions you can create with Adobe Captivate.

About Variables in Adobe Captivate

All programming languages use variables to temporarily store values that can then be used by other parts of an application. Some programmers like to think of variables as being ‘containers’ or ‘buckets’ into which you place values such as numbers or strings of letters. However, technically variables work more like pointers or identifiers that link to or reference their values.

To use Adobe Captivate’s Advance Actions you don’t really need to worry too much about the technical aspects of how variables work in programming languages. All you need to know is that variables store values and you can usually change those values using advanced actions. In Captivate’s terminology, you are said to ‘assign’ the value of a variable when you use an action to change it.

Captivate has a few different types of variables, and you need to become familiar with all of them in order to create advanced interactivity.

System variables

These are variables that come pre-defined with Captivate. You don’t need to create them (in fact you cannot create them yourself). They allow you to monitor or modify what the system, i.e. your e-learning module, is doing at run-time.

Of the 70 or more system variables available in Cp7, only a dozen or so can be assigned values via advanced actions. The rest are READ-ONLY at run-time (as indicated in the appendix list mentioned above). Additionally, you cannot change names of any system variables, and since all variable names must be unique, you cannot use the name assigned for a system variable as the name of a user variable.

User variables

These are variables that you, the Cp author, can create and name as you choose…as long as you don’t contravene certain variable naming rules (see below). Furthermore, any name you assign to a user variable must not conflict with Captivate’s internal functions, reserved keywords, exposed system variables, or other hidden variables.

Hidden variables

There are of course hundreds of other hidden variables that Captivate uses internally, but you might as well forget about trying to use these in your e-learning. From time to time some Cp developer will stumble across one of these by accident, usually as a result of accidentally naming a user variable with one of the 150 or so reserved keywords.  The reason Adobe doesn’t publish lists of these hidden variables is that it might encourage technically savvy e-learning developers to try using them and then inevitably break some essential run-time function, or even corrupt their project file entirely.

Variable naming conventions

Naming Cp user variables is a bit like naming your children. It’s worth taking some time to consider the ramifications of the moniker you assign, because once it goes on the birth certificate and the ink is dry it can be a major issue to change at a later date.

Similarly, whenever you create a new user variable you should pause and think carefully about the name you give it because once you assign a name to a user variable and save the new variable from then on you cannot change the name. You’re stuck with it.

If you later decide the name was a mistake, your only option is to create another variable with the correct name and then go through all the places (captions, advanced actions, etc) where you used the previous variable and reassign them to the new one. That’s more trouble than you want, believe me.

So here are some basic rules to follow when naming user variables:

You cannot begin a variable name with a number or a space character.

If you try to do so, Captivate will warn you that this is not allowed (as shown below).

Some Cp authors like to begin all user variables with the letters V or v_ so that variables can more easily be identified in lists. Just remember that variables are sorted alphabetically in the dialog list.  So if you do start your variables with the letter V, then they will all end up right at the bottom.  It’s your call, but I prefer to name my variables starting with a word describing their key function.

NEVER use reserved keywords

There are around 150 ActionScript keywords that Captivate reserves for its own internal use and you must never assign any of these as the name of a user variable. If you don’t believe me, check out this page on the Captivate help system.

Although in theory Cp should detect and prevent you from using reserved keywords as variable names, it doesn’t always seem to do this flawlessly. If you should inadvertently happen to fall into this trap, it could prevent you from being able to publish your project, throw error messages, or in a worst-case scenario, corrupt your project and render it unusable.

Names must be unique

All variable names must be unique across any single CPTX project file. You can however use the same variable names in different modules of a course. In fact, you may need to do this when persisting variable values from one module to another.


CamelCase is a naming convention often used by software programmers. Words in the name all start with a capital letter, thus making the capital letters stand out like the humps on a camel. It’s not mandatory, but it is popular with professional programmers because it makes the words in a variable name easier to read at a glance and understand. Look at the example below and ask yourself which of the names is easier to read quickly:

  • myreallylonginvolvedvariablename
  • MyReallyLongInvolvedVariableName

Names should be intuitive

Once you really get going with Cp interactivity it’s quite likely you’ll be creating dozens, scores, or even hundreds of variables in a single CPTX project file. (My personal record is just under 350 variables in a single module.) So it’s wise to give some careful thought to how you might structure your variable names so that they will still make sense several years from now when you (or someone else) might need to come back and edit or update your course. It’s wise to avoid names that will only make sense to you and nobody else.

Another suggestion you might follow is to use a prefix on your names that tells you what overall part of the interaction each variable belongs to.  For example, if you have a number of variables that are all used in the course navigation, you might begin all of their names with the word Nav_ as follows:

  • Nav_NextButtonState
  • Nav_BackButtonState
  • Nav_TOCItem

If you have a number of variables involved in a specific quiz interaction, then you may use a prefix such as Quiz_ or similar. Take a look at the screenshot below of part of the Variables dialog in one of my own projects. Can you tell from the names what each variable might be used for?

Whatever naming convention you follow, the point is that each variable name should be intuitive enough to make its purpose obvious without the next developer being required to laboriously trawl through the Variables dialog looking for descriptions. And while we’re on the subject…

Always add descriptions

Even though you go to great lengths to make your variable names self-explanatory, it’s still good to include text in the Description field of the Variables dialog to document what the variable will be doing or where it might be used. For example, if a particular variable will be supplying essential data to one or more advanced actions or conditional advanced actions, then you might list them in the description. Since most e-learning developers never document their interaction designs for posterity, these descriptions may be all someone else has to go on when they are asked years from now to figure out how to update your project file.

Boolean variables

One of the most common types of variables that you will need to use when working with advanced actions is the Boolean variable. This data type was named after George Boole, a mathematician who developed Boolean Algebra way back in the 1850’s, well before computers were ever thought of.

Unlike most variables that can hold any number of possible numeric or string (text) values, a Boolean variable can only hold one of two values. These are usually 0 or 1, TRUE or FALSE, YES or NO. A Boolean variable acts a lot like a light switch. The light is either ON or OFF.

You can set the value of a Boolean variable using the assign action, either as part of a single action, standard action, or conditional action. You’ll find Boolean variables particularly useful in conditional actions to store the result of a condition that checks whether something is correct or incorrect.

Migrating variables from one project to another

Captivate has traditionally had no way to move variables or advanced actions from one project file to another. This deficiency has always been a huge hole in the application’s otherwise fine functionality.

But then Captivate 7.0 added the ability to use shared actions, with ability to export actions from one project and then import the same actions into another. One less-known feature of shared action functionality was the fact that all variables referenced by the shared action are migrated along with it and recreated in the new project file location at the time of import.

With the release of the update patch for Captivate 7.0.1 in mid November 2013 Adobe went one step further to allow any variables referenced by actions on a copied slide to be added to any project this slide was pasted into. This certainly helps.

However, there is a catch. If the target project already contains variables of the same, the incoming variables are renamed with a number appended to the end.  So watch out for that issue.

About variable data typing

In most programming languages variables are ‘typed’, meaning that they are deliberately restricted to accept and store only certain types of values such as Booleans (0 or 1, true or false, yes or no), integers (numbers), or strings (text).
By contrast, Cp user variables are not typed. They’ll accept almost any numeric or text value you want to throw at them. (System variables are mostly READ-ONLY so their data is usually also of a fixed type.)

Although on the surface this freedom to store any type of value in a variable might seem like a good thing, it can also sometimes get you into trouble. For example, you may end up inadvertently trying to perform math functions on a string of text, or concatenating a number, which of course won’t work.

So this means the onus is on you, the Cp developer, to keep track of what type of data your variables should hold. And that’s a lot easier to do if you keep your documentation and descriptions up to date.