Be unique! (labeling actions)


OK, I already confessed about being a labeling freak. A while ago I have tried to list all the advantages of labeling slides, objects, variables, actions Some reasons for labeling. But I never imagined that this would cause me troubles one day, make me bumping my head because I couldn't figure out what was going wrong. I owe it to you, loyal reader and follower, to avoid the same pitfall and will try in this blog post explaining what I will hopefully never forget again.

Unique labels

As you can detect from the title, the issue I had was linked with a label not being unique. I will first list up the rules to keep in mind for this uniqueness, for the different categories of items. Do not forget as well that all labels are case sensitive: 'One' is considered different from 'one' and from 'ONE'.

Object labels

Each object needs a unique label, even though it has already a unique ID. That is not really a problem, because when trying to assign a label to an object that is already attributed, Captivate will show this message
is either a reserved keyword or is already assigned to another item. Provide a different name for the item.
This means that Captivate is checking object label uniqueness all the time, and I feel safe.

Slide labels

You can assign the same label to different slides, Captivate doesn't apply this rule to slides. You can even use a label that already has been used for an object, a variable or an action. No problem.

Variable labels

Trying to apply the same label to a second variable will also result in a checkup and message by Captivate:
This variable name is already in use. Enter a new name.
Fine, feeling safe again, isn't that what software is meant to do? And Yes, you can assign the same label to a variable that is already assigned to an object. A typical example is a Text Entry Box. If you keep the default labels assigned by Cp both the TEB itself as the associated variable have the same label: Text_Entry_Box_1

Action labels

If I assign an identical label to a second advanced action, at the moment I want to save or update the script, my guardian angel Captivate tells me politely :
The script name is already in use
It will stop the saving operation and leaves the script intact, I can change/edit the action name and save it successfully. This rule is applied to all actions, no difference between conditional or standard actions they all need a unique label. As for the variables, you can use a label that is already given to an object and/or a variable safely. That can help identifying them if you have a large bunch of actions. Examples:  if you need an advanced action for each slide on entering, you could assign the same label to the slide and the action; if the action has to be triggered by a button use the same label etc.

Decision labels

In a conditional action you can have different decisions, also called 'internal actions' in contrast with the complete advanced actions that are called 'external actions'. Default label here is Untitled, but I like to change that to a more meaningful one. And like for slide, apparently here it is possible to have identical labels, no checkup by Captivate. But why should one use identical labels?

External actions - internal actions

I'm smiling because now I see virtual question marks in your eyes: "What was the issue then?'. Let me try to explain, what I was told by the Adobe team as an answer.
The external actions are the total advanced actions, conditional actions as well as standard actions. Captivate will always check if a new label is unique and offer you the message I described above under 'Action labels'.
In a conditional action, each decision is considered an internal action. When you create a new decision in an conditional advanced action, and label it, Captivate will also check something:
 Captivate checks if the label attributed to a new internal action isn't already attributed to an external action !
This seems strange to me, because it doesn't even check the uniqueness for the different internal actions in one conditional action. It would have been OK however if I got a similar message as for the actions, that told me that 'the script name is already in use'.
BUT!!! Captivate doesn't tell you anything, from the second decision on it just deletes the internal action that you wanted to save without any warning. This is a bug, that is still there for the moment.
Two examples for you to try out and to understand the problem better :

Example 1 (if you are lazy, watch the recording of this scenario)

  1. Create a standard action, label it test
  1. Create a conditional action, label it TEST: no problem, due to the case sensitivity, Captivate will accept this label when saving.
    1. create a first decision, default label will be 'Untitled', save the action
    2. change the label of this decision to TEST,  same name as the total conditional action, try to save and you'll get a message (great!) "Script update is not successful", Captivate did his homework.
    3. since the label was rejected, change it again to test (which is already attributed to another external action); again message appears, change to another label and save.
    4. create a second decision with name test and fully script it, choose Update, you get the message 'Script update successful', you trust CP and clicks on OK: and your second decision disappears...Captivate when checking did detect that the name already existed for an external action, but gave you the wrong message and deleted without warning.
If you revert 1 and 2, create the conditional action before the standard action, everything will work fine: when creating the standard action test Captivate only checks the other external actions, not the internal action etest that already xists in the conditional action.

Example 2

  1. Create a standard action, and label it Untitled
  2. Create a conditional action, leave the default name for the decisions set to Untitled
    1. create the first decision (Untitled), save the action and you get the message 'The script name is already in use', change the decision name
    2. create a second decision (Untitled), try to update, you get the message 'Script update successful' and when clicking OK, second decision is deleted.

Conclusion - tips

  • Never create an advanced actions with the label Untitled
  • If you have to create a conditional action with multiple decisions - internal actions, be sure to have a list with the names of the already created actions ready. I tend to keep that list in the scratch area of Captivate.
  • If you can cope with it, do not have too much decisions, leave their labels to Untitled (do not like that as you know)
  • If you label decisions in a conditional action, starting with the second decisions PLEASE check your list with existing action labels before clicking on Update.

Update: new features in release 5.5 that I used

Since Captivate 5.5 has now been officially released, I can tell you that the splash screen of my video was created with the new Gradient feature of this release. This gradient tool is fully customizable and a great way to enhance objects. In the movie I also used the new Shadow and Rotate features that are now available for all kind of objects. Both of them were used on the end slide: the Text Animation 'Where is my internal action'? is rotated with the Transform Accordion and I applied a shadow to the characters. There is a screenshot below. BTW: in the SWF published in the post Extended widgets for custom MCQ and T/F Questions I used the shadow feature a lot of times, explore...
2 responses

Thank you for all of your work on Captivate-- I found one of your articles on Adobe's website, and it has helped me take my Captivate knowledge to another level!

I'm wondering if you could give me some advice regarding the "Multiple TEBs one Submit button" issue that you wrote about on Adobe's site. I followed your steps and everything worked perfectly. I did, however, run into one problem that I'm hoping you can shed some light on:

Since we are not using a Submit button with each TEB, the user input is only being validated against the value of "v_correct" and not the HUD for the TEB. Therefore, the user interaction with each TEB is not being reported to the quiz.

Is there any way around this?

Thank you and keep up the helpful posts!

Thanks for the kind words! This blog post was meant as an answer to a question on the forum, no requirement to transfer the data to a LMS.
If you want to report, you have to validate every TEB. Once I worked out another solution for someone where each TEB was validated, by changing the Submit button in transparent button with no Text in it, and putting that button on top of the next TEB. This meant however that the sequence of the TEB’s to be filled in was not free: the first TEB had its (invisible) Submit-button on top of the second TEB-field, etc. Hope you get the idea?