Note that some variables available in CP3 and CP4 are no longer available. The following list should be exhaustive for CP5; variables for previous versions of Captivate have been purposely left off this list. I also purposely left off some publicly accessible (but useless) movieclips and objects.

While most people seem to focus on using Captivate variables natively within a Captivate project via the Variables menu or widgets, my focus has been figuring out how accessible/usable they are via JavaScript. Thus you may find small differences between my list and other people’s lists, and differing opinions regarding the usefulness of some variables and publicly accessible movieclips. Regardless, the items below should be accessible via every method: widgets, JavaScript, and the native Variables support in Adobe Captivate.

If you know of any variables that I missed, please leave a comment. Thanks!

Update: Kurt Melander has kindly converted this list to PDF format if you’d like to download or print it. Thanks, Kurt.

Complete List of Variables for Adobe Captivate 5 is a post from: pipwerks.com. Unless specified otherwise, all code is licensed under an MIT-style license. All other content is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Related posts:

1. CaptivateController Updated to Support Adobe Captivate 5
2. Captivate 4 variables gone wild
3. Control a Captivate SWF using JavaScript: The basics

As you may have heard, Adobe Captivate 5 is a complete re-write of the Adobe Captivate application. As such, there are a few significant changes under-the-hood. For example, Adobe Captivate 5 does not support ActionScript 2, and will only publish to ActionScript 3. The Captivate developers eliminated a few of the old system variables while adding a few new ones. Showing and hiding the playbar now works very reliably (yay!). Most notably, the developers added extra ExternalInterface support via the cpEIGetValue and cpEISetValue callback functions while eliminating the cpSetValue callback, which explains why the previous version of the CaptivateController didn’t work with CP5 SWFs.

As for the updated CaptivateController, it works the same as the previous version. Most of the changes were under-the-hood, so you shouldn’t need to edit any of your code, and should be able to drop this new version on top of your old one. No system restart required!

• Download the updated CaptivateController
• CaptivateController documentation
• View the test suite
• Complete list of variables for Adobe Captivate 5

If you encounter any bugs, please let me know by posting in the comments. I’d also be happy to hear any success stories you may have.

CaptivateController Updated to Support Adobe Captivate 5 is a post from: pipwerks.com. Unless specified otherwise, all code is licensed under an MIT-style license. All other content is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Related posts:

1. Complete List of Variables for Adobe Captivate 5
2. CaptivateController updated
3. Introducing the CaptivateController

So what the heck is g_intAPIType, and why does changing it make a difference?

The short version is this: Captivate courses, when published for SCORM, typically use one of two communication methods: FSCommand or getURL. FSCommand works really well in some browsers, such as Internet Explorer, but has spotty support in others. getURL works in all browsers, but uses a more complicated communication system when sending data to your Captivate file from the LMS. It also makes a lot of clicking sounds.

Setting g_intAPIType to 0 means you’re forcing Captivate to use FSCommand in all browsers. Setting g_intAPIType to 1 means you’re forcing Captivate to use getURL in all browsers. If you don’t manually specify the value of g_intAPIType, Captivate’s SCORM template includes some browser sniffing that automatically sets g_intAPIType to 0 for Internet Explorer and 1 for all other browsers.

Want to know more about FSCommand versus getURL? Colin Moock wrote a good FSCommand tutorial that covers the basics.

Note: ExternalInterface has replaced both of these methods as the favored Flash-to-JavaScript communication method, but Captivate has not caught up yet.

Adobe Captivate: What the heck is g_intAPIType? is a post from: pipwerks.com. Unless specified otherwise, all code is licensed under an MIT-style license. All other content is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Related posts:

1. CaptivateController Updated to Support Adobe Captivate 5
2. Customizing SCORM Manifests in Captivate and Articulate Presenter
3. Actionscript, JavaScript, and SCORM

But what happens if the browser window containing your course is closed by the learner before the course finishes sending data to the LMS? If you’re not careful about how you’ve coded your course, you can lose some of the data. For example, if a learner completes the course and then immediately closes the window, the course might not have had enough time to tell the LMS about the completion, preventing the completion from appearing in the learner’s record.

It’s best to be proactive about this by setting up an event handler for the browser’s unload and onbeforeunload events. Whatever code you place in these events will execute when the browser is closed. In a SCORM course, you should place a commit (save) and terminate (quit) command in these events to ensure the SCORM data is properly persisted in the database and the session is properly terminated.

The code is pretty straightforward (this example uses SCORM 2004):

//Assuming API refers to your SCORM API
//and API_isActive returns a boolean indicating
//whether your API has already been terminated
 
var unloaded = false;
function unloadHandler(){
   if(!unloaded && API_isActive){
      API.SetValue("cmi.exit", "suspend"); //Set exit to whatever is needed
      API.Commit(""); //save all data that has already been sent
      API.Terminate(""); //close the SCORM API connection properly
      unloaded = true;
   }
}
window.onbeforeunload = unloadHandler;
window.onunload = unloadHandler;

Since some browsers support onbeforeunload and others don’t, we use the unloadHandler on both onbeforeunload and onunload, just to be safe. If a browser supports both of these events, the unloaded boolean ensures the scorm.quit function is not executed more than once.

If you’re using the pipwerks SCORM wrapper, your code will be even simpler, because the pipwerks wrapper automatically checks the API’s availability before performing any action. The wrapper also sets the cmi.exit/cmi.core.exit parameter for you.

var unloaded = false;
function unloadHandler(){
   if(!unloaded){
      scorm.save(); //save all data that has already been sent
      scorm.quit(); //close the SCORM API connection properly
      unloaded = true;
   }
}
window.onbeforeunload = unloadHandler;
window.onunload = unloadHandler;

SCORM Tip: Use an onunload handler is a post from: pipwerks.com. Unless specified otherwise, all code is licensed under an MIT-style license. All other content is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Related posts:

1. SCORM Tip: Don’t forget to commit!
2. SCORM API Wrapper updated to auto-handle exit and status
3. Adding SCORM code to an HTML file using the pipwerks SCORM wrapper

The pipwerks scorm.save() function is a shortcut for SCORM’s Commit (SCORM 2004) and LMSCommit (SCORM 1.2) methods. Invoking commit in SCORM means you are explicitly instructing the LMS to persist the data you’ve sent. In other words, you’re telling the LMS to save your stuff!

When sending data from your course to the LMS, the data is travelling from the course window to the LMS via JavaScript and is stored in the browser. The SCORM spec gives LMSs the flexibility to decide when to transfer this data to the database. Some LMSs will not immediately write the data to the database because it can clog up the system; they prefer to queue up the data and send it in bunches. This explains why some courses will be successful in sending the data from the course to the LMS, but the LMS doesn’t seem to save the data. You didn’t tell it to! I know, I know, it seems daft, but it happens. So, to be safe, ensure your data gets saved by instructing the LMS to save the data.

Note that some LMSs will automatically commit at the end of a session, usually by detecting if the course window was closed (window.onunload) or if a certain CMI call was invoked, such as setting the completion status. However, you should never take your chances, and should design your SCO to commit regularly. Just be careful not to overdo it.

The rule of thumb is to invoke a commit (save() if you use the pipwerks wrapper) after a significant chunk of data has been sent to the LMS, but not after each and every call:

NO (committing too frequently):

scorm.set("cmi.location", "some string indicating location");
scorm.save();
scorm.set("cmi.suspend_data", "your custom suspend_data string");
scorm.save();
scorm.set("cmi.score.raw", 80);
scorm.save();

NO (not committing enough):

scorm.set("cmi.location", "some string indicating location");
scorm.set("cmi.suspend_data", "your custom suspend_data string");
scorm.set("cmi.score.raw", 80);

YES (one commit after a short series of ’set’ calls):

scorm.set("cmi.location", "some string indicating location");
scorm.set("cmi.suspend_data", "your custom suspend_data string");
scorm.set("cmi.score.raw", 80);
scorm.save();

SCORM Tip: Don’t forget to commit! is a post from: pipwerks.com. Unless specified otherwise, all code is licensed under an MIT-style license. All other content is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Related posts:

1. SCORM Tip: Use an onunload handler
2. How to add basic SCORM code to a Flash movie
3. Really simple SCORM AS3 wrapper example