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 people 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 in the computer or browser’s memory.
To use Adobe Captivate’s Advance Actions you don’t really need to worry too much about the technical aspects of how variables work ‘under the hood’ 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 and are designed to allow you to monitor or modify what the system, i.e. your e-learning module, is doing at run-time. However, you cannot create new system variables yourself to add to the Captivate application and you cannot change their names and, since all variable names in a Captivate project must be unique, you cannot create User Variables (explained below) and use the same name assigned for a System Variable.
This PDF document contains a printable list of all System_Variables_in Adobe Captivate 2019
Of the 70 or more system variables available in Captivate, only a dozen or so can be assigned values via advanced actions. These are known as Command Variables and always begin with the prefix cpCmnd.
All other System Variables are READ-ONLY at run-time (as indicated in the appendix list mentioned above) which means you cannot dynamically change their values, only reference them for information about the current status of the system.
User variables
These are variables that you, the developer, 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 System 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 clever 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 mentioned above. 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 Captivate 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 developers like to begin all user variables with the letters V or v_ so that variables can more easily be identified in lists. However, this is not really necessary because variables and other types of Captivate slide objects (e.g. shapes or captions) are never shown side-by-side in the same selection lists. Also, since variables are sorted alphabetically in the dialog lists, if you do start your variables with the letter V, then they will all end up right at the bottom of the list and you might find yourself scrolling down to them all the time. That can get tedious. It’s your call, but I prefer to name my variables starting with a word describing their key function.
See this example where some variables are related to debugging functionality while others are related to displaying times and dates:
NEVER use reserved keywords as variable names
There are around 150 keywords that Captivate reserves for its own internal use and you must never assign any of these as the exact name of a user variable, but you can use keywords as part of a name.
Check out this page on the Captivate help system.
This PDF document contains a printable list of all Reserved_Keywords.
Although in theory Captivate 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. So, better to avoid the keywords just in case.
All variable names in a project 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.
UseCamelCaseNames
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 descriptive
Once you really get going building interactive e-learning projects 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 and it was functioning perfectly well. The problem with having so many variables is that you may forget what they are for. So, it’s wise to give some careful thought to how you might structure your variable names so that they are easy to locate in lists and will still make sense several years from now when you (or someone else) might need to come back and edit or update your course. So, 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…
Keep variable names less than 25 characters in length
The more descriptive your names are the better. But you also need to keep the names short enough to be easily read in any dialog box where they are likely to appear. In practice this means that variable names in Captivate need to be no more than about 25 characters in length. This means that although all of the names in the screenshot above can be easily seen in the Variables dialog, the ones with more than 25 character would have the ends cut off when seen in the Advanced Actions dialog. Less is more.
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 Standard Actions or Conditional Actions, then you might list the names of their related actions 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. You might go to all the trouble of documenting this same information in a document when you complete the project, but there’s no guarantee that document will still be easy to locate in several years time when the next person comes along to work on the same files. However, if your ‘documentation’ is right there inside the project files, it’s always going to be available to the maintenance developer.
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, Conditional Action, or Shared Action (if it is one of the parameters). 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
For many versions Captivate had no way to move variables or actions from one project file to another. But now you have two options to achieve this migration.
One ways is by using Shared Actions, because they have the ability to convert actions into a file that can be stored in the Captivate Library, exported from the initial project and imported into another. When this is done, 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.
The other way is simply copy any slide or interactive object (e.g. button) that has events set to trigger an Advanced Action and then paste that slide or object into another project. The related actions and variables are all then recreated in the new project.
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. And since we cannot rename variables after they are created, this can sometimes result in a bit of a mess. 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 Captivate 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.
