Variables

PLEASE NOTE: This information was originally posted on my website back in 2014. The method explained in the videos linked below has now been greatly simplified in more recent editions of Adobe Captivate. Instead of hiding and showing lots of grouped objects it is now possible to achieve very similar results using Object States.

Have you ever wanted to add more interactivity to your e-learning course by including a Dynamic Menu Slide with links to sections of your content? You would not normally use this type of navigation for strictly linear e-learning modules.  But if the course module has several content sections and they can be done in any order, a menu slide makes good sense.  

Well in these two video tutorials I show you how to do just that with several progressively more complex examples, starting from a bare bones simple example, up to menu slides that include visual feedback to indicate which items a user has interacted with, and finally to a very complex menu slide.

Start with simple examples first!

The first video below explains how to create very simple menu slides that require only interactive objects. Then it moves on to two more complex examples that require custom User Variables and Conditional Advanced Actions. Don’t worry if yiou are unfamiliar with these concepts as I explain how everything works from the ground up.  

Watch the first YouTube video below to see how all of this is done!

Taking things to the next level

The Infosemantics template for Adobe Captivate has a built-in Dynamic Menu slide that is far more complex than the simple examples explained in the video above. The next video below builds on the concepts explained above and showcases how to use the dynamic slide from the Infosemantics project template. 

In this tutorial we explain how to create, edit, and delete Adobe Captivate variables. One of the easiest tasks you’ll ever perform in Captivate is to create a new user variable. This is just as well, because if you intend to be creating complex interactivity in your e-learning, you’ll definitely be creating lots of variables!  

Create a User Variable

1. From the Project main menu, select the Variables option.
   
2. When the Variables dialog opens, click the Add New button.
   
3. Type the name of your user variable. I recommend you pause before going to the next steps and finalising the variable name because once you save the variable you cannot later change its name.  Check out the recommendations on this page about variable naming.
4. Enter a default variable value (if applicable) and provide a Description of its purpose.
5. When you are finally happy with the details, click the Save button.
   
   Your newly-created variable will now be listed in the lower part of the Variables dialog. Variables are listed in alphabetical order, with only two exceptions. The user variables called cpQuizInfoStudentID (used for Internal Server Reporting) and cpQuizInfoStudentName (used for capturing the student name variable from a learning management system). For some reason, Adobe has opted to have these variables always sort to the bottom of the list of variables.

Edit a User Variable

Once you’ve created a number of user variables from time to time you’ll need to change something. Since you cannot change the variable’s name, your editing options are limited to altering the default value, description text, or removing/deleting the variable altogether.

1. Open the Variables dialog and select the variable you want to change. (The Update button is initially disabled until you make some detectable change to the variable properties.)
2. You cannot edit the variable’s name. Edit the Value or Description fields as needed and then click the Update button. (After making the change, the Update button again becomes inactive.)
   

Remove (Delete) a User Variable

As you develop a project you may find that some of the variables you create become redundant and need to be removed (perhaps because you had to create a duplicate variable with a different name). It’s a good idea to take out the trash by deleting these unwanted variables because they can waste browser memory and slow down run-time performance.

The process is simple enough…but there are some important issues to be aware of:

1. Open the Variables dialog and select the variable to be deleted.
2. Click the Remove button.
   
3. Now things get a little more complex. Please note the following caveats about removing variables:

• You can only remove user variables, not system variables.
• You can remove a variable referenced by a single action that assigns its value, but this will result in the action being reset to Continue.
• You can only remove user variables that are NOT currently being used to display values in screen objects such as text captions or shapes. Additionally, you cannot remove any variables currently referenced by Standard or Conditional Actions in your project file. If you try to remove one of these referenced variables, Captivate will show the following warning message.
  
  Unfortunately, this warning message doesn’t give you any information about which specific slides or advanced actions use the variable and need to be modified before you can remove it. In a large project with many slides and actions, this can be like trying to find a needle in a digital haystack.

Trace variable usage

Just click the Variables dialog Usage button (similar to the one on the Advanced Actions dialog) to show where the currently selected variable is referenced on any slide in the project, as well as which specific run-time event is used to execute the action involved.

This now makes it extremely easy to do any required project file housekeeping. If your variable is not used anywhere, you’ll just see a dialog simply saying “Item is not currently in use” and you can safely delete it.

However, there appears to be one caveat. Variables that are referenced in widgets don’t get taken into account by the Usage dialog. So if you have a lot of widgets or interactions (which are also widgets) in your project, you may need to check them manually before starting any round of mass deletions.

One of the easiest ways to make use of Adobe Captivate variables is to display their values in text captions, shapes, and Smart Shape objects at run-time. In the example below I show how this is done by inserting several display fields into a single text caption.

How to display project information

Let’s imagine your project needs to have the e-learning author’s name and contact information appear on a slide at run-time. Here’s how you could do that:

1. Create a new blank project and open the File > Project Info… (This is quicker than navigating to the same dialog location using Edit > Preferences > Project > Information.)
2. Type relevant information into the fields provided.
3. On another slide in your project file, insert a text caption and some text to indicate the type of information it provides.
4. Place your mouse cursor at the point in the text caption where you want to insert the variable display field.
5. On the Properties tab > Format accordion, click the Insert Variable icon.
6. When the Insert Variable dialog opens, change the Variable Type to System and from the Variables drop-down list select cpInfoAuthor as the variable to be inserted.
7. Pay close attention to the default value shown in the Maximum length field. It has some serious gotchas!
   Gotcha # 1: In earlier versions of Cp this field was set to 15 characters by default. This length is fine if all you are doing is displaying a number, identifier code, or slide name. But it’s usually too short to display personal names, company names, course names, etc. In Cp7 the default length has been increased to 50 characters, but you can change it to specify any length up to about 250 characters. So give careful thought to how much information you need to display and set the field length accordingly.Gotcha # 2: There is a bug in versions prior to Cp7 where if you happen to be inserting a number of variables one after another, the Maximum Length field randomly reverts to a value of 0. So be sure to take a moment to check this field before hitting the OK button.

   Gotcha # 3: If you happen to guess wrong about the required number of characters to allow as the length of the display field, you cannot easily change it. You must delete the inserted field and re-insert another one to change the display length. So it’s usually wise to bet a little on the high side to be safe.

   

8. Once you’re happy with the details of the inserted variable, click the OK button. Your variable will appear by name, surrounded by double dollar signs (e.g. $$cpInfoAuthor$$).
9. Repeat the last few steps to insert any other variables in the same caption. It should then appear something like the example screenshot shown below.
10. Publish your project to see how the variables are displayed in the caption. They should look something like the screenshot below.

Why not just type the variable name with $$ characters on either end?

Perhaps you’ve read throught the steps above and wondered if you can insert a variable into a caption or shape by just typing the variable name and adding $$ characters at the beginning and end. Yes you can.

However, while it may be slightly faster, the downside to this method it that it doesn’t allow you to set the number of characters for the maximum display length. It will just assign the default amount, which is only 15 characters for Cp versions 5 through to 6.1 and 50 characters for Cp7.  The 15 character default was far too small, and even 50 characters will sometimes be insufficient.

So, call me a control freak, but I still prefer to insert variables via the dialog method and set the display length myself.

Overcoming dynamic text formatting issues

When you insert a variable into a caption or shape, don’t be surprised if you need to fiddle around with the formatting a bit before it all looks right at run-time. These formatting issues are due to the fact that normal caption text is ‘static text’ (because it doesn’t change at run-time) while variable display text is ‘dynamic text’ (because it can change depending on the current value of the variable being displayed). In Captivate’s published output, captions containing static text are actually converted into images. But since this means the text becomes an image too, this approach would not allow dynamic text to change on-the-fly at run-time. So, static and dynamic text strings are kept separate. The result can be certain inconsistencies in visual formatting.

For example, some early versions of Captivate did not allow dynamic text to be indented. If you applied indenting in Edit mode, the indenting disappeared at runtime. If you added variable text into the middle of a paragraph of static text in a caption, none of that text would honor the applied formatting. This often resulted in captions with text unattractively crammed into the top-left corner or positioned hard against the left side of the caption. There were also notable differences in the aliasing of the text. For example note the differences in the two run-time captions below from Cp 5.5.

The text in the caption above left is just typed in. The one on the right is displaying text supplied by a user variable. The workaround for such formatting issues is to place dynamic text inside a transparent caption positioned on a layer above another caption. This made it appear as if the underlying caption contained the dynamic text when in fact it was just acting as a background.

Fortunately, these issues have been steadily diminishing with each new version and it’s now quite difficult to tell static and dynamic text apart as you can see from the Cp7 examples shown below.

Hopefully one day, in some future Cp version, there will be no discernible differences at all.

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.

This PDF document contains a printable list of all Reserved_Keywords that must not be used in Captivate as the name of a variable.

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.