Tip 5: Parameters (Shared Actions)


First 4 tips in this series were valid for both Advanced and Shared actions. 

This blog is only for Shared actions, which are still not very popular amongst the Captivate developers. In my workshop at the Adobe eLearning World Conference I have demonstrated their power, even for unexpected uses. For each action I develop in my projects I always take a little time to reflect on this question 'Will this be useful as Shared action'? Result is that more than half of my actions end up to be Shared, not Advanced actions. My Libraries with useful shared actions are growing all the time, and have saved me already many hours of work.

In this article I will focus on tips for choosing Parameters to make the shared actions as flexible as possible. When saving an action as Shared action, you get a dialog box where compulsory and candidate parameters will appear:

  • Compulsory parameters: include all objects, audio clips, states... which you have in the advanced action dialog box, with the exception of literals and variables. You recognize them by the appearance of a yellow exclamation sign. When you add a description to such a line and indicate something as placeholder for the parameter the yellow sign is replaced by a green checkmark.
  • Candidate parameters: are the literals and variables which you find in a condition, or in commands like Increment. They get a green checkmark, but by using the checkbox you can convert them to parameters as well. 

Here is a screenshot of the dialog box for a toggle button. You'll see the compulsory and candidate parameters.  Description for the compulsory parameters has not yet been typed:

General Tips

Using several instances of one shared action to replace duplicate advanced actions leads normally to smoother projects, less risk of choking Captivate and even lower file size. However it is important to keep the number of parameters to assign on each instance not too high. Personally my goal is to have a maximum of 6-7 parameters. If you really need more of them, but appreciate the ease of transferring shared actions to new projects, remember that you can use each shared action as template for advanced actions. You can use that knowledge to create duplicate advanced actions if the number of parameters is too high. Labeling (see Tip 1) remains very important as well, because of the filtering (Tip 2) which is possible in the dropdown lists for parameters. You'll find some more tips below for the two types of parameters.

Compulsory parameters

Depending on the action using those parameters, they are either very specific (only one type) or they can be flexible and cover more than one type. Examples:

Show/Hide actions: they can aim at lot of object types. All graphics (bitmap or SVG), video, but also audio objects (invisible objects which have audio attached), learning interactions, but also Groups! These are probably the most flexible actions, and you may consider to replace a multistate object approach by Show/Hide for that reason.

Change State: not so flexible, they need always two parameters which are the multistate object and the state. Whenever possible try to use 

Go to Next State/Go to Previous State: you only need the multistate object as parameter

Assign can be used with 0, 1 or 2 parameters. You need 0 parameters if using two variables which are not defined as parameters, 1 if you have a literal which is no parameter or one variable defined as parameter, 2 if you have both literals/variables defined as parameters. 

Toggle: can only be used for Boolean variables, better choice than Assign because you have 0 or 1 parameter (the variable which could be defined as parameter).

Play Audio: needs an audio clip as parameter.

Apply Effect: only the object or group to which you want to apply the effect can be a parameter, not the effect itself. In most cases you'll want to use a custom effect to have the correct setup parameters.

Candidate parameters

Candidate parameters are variables and literals.  They appear in conditions, both for IF and WHILE setup, but also in the commands Assign, Increment, Decrement, Expression. 


If a variable in a shared action is not defined as a parameter, it will automatically be created when you import the shared action to a new project, including its Default value and description. One of the shared actions in my actions library is meant to avoid having to create much used variables in new projects. See this screenshot:

I also use that action as template for the many Reset actions needed On Enter for slides.

When you define a variable as parameter, this automatic creation will not happen!

Before defining a variable as parameter, you need to check if that variable is used multiple times in the action. Know that when assigning a variable to the parameter, it will replace that variable wherever it has been used in the action. I will try to explain by an example. If you ever created an advanced action for 'Forced View', where the appearance of a Next button is postponed until all clickable objects on the slide have been used at least once, this action for the first clickable object will look familiar:

In this project, the first clickable object is SV_Decision.  That object has a custom state showing Info, and acts as a toggle button. On a second click the Normal state will re-appear. Its tracking variable is v_1, a Boolean, which will get the value 1 on each click. On the slide 4 of those buttons need to be clicked.  For the three other buttons both the name of the button and the tracking variable need to be edited in a duplicate advanced action. The second decision checks the 4 tracking variables, shows the Next button if all have the value 1.

In this setup you cannot convert this action to a shared action. It would need 3 parameters:  the Next button, the button itself and the tracking variable. But if you replace the first variable by the second variable, that will also happen in the second decision, thus leading to a non-functional second decision where only 3 variables are checked. Have a look at this action:

In this action 2 extra variables are used:

  • v_counter: will be incremented only on the first click; that makes the third checking decision easier, and the tracking variable v_1 which appears twice can be replaced by any other tracking variable.
  • v_max: instead of the literal '4' this new variable makes the action more flexible. It can be used for any number of clickable objects on the slide. The value of v_max (4 in this case) can be assigned either directly in the Variables dialog box, or with the On enter action of the slide. You could also define that variable as parameter if you prefer.


Be very careful with literals as parameters. My replacing it by a variable in the previous example gives you a possible workaround. Especially if you have multiple literals in an action, defining them as parameters can lead to issues.  Look at this variant on the same situation described above:

It could be possible to define the value '4' in the last decision as a parameter, so that you can use the action for any number of clickable objects (alternative for the variable v_max). However, if you should define the '1' as parameter, changing it in an instance of a shared action would lead to changing it in 3 locations of the action! 

My recommendation: avoid defining literals as parameters!