In 2008 I posted a quick writeup on how I dealt with cross-domain security issues for some of my e-learning courseware. Since then, I’ve had a lot of people contact me with various questions and requests for a working example. Tonight I decided to revisit the topic and whip
While updating my CaptivateController script I noticed there have been some changes to the Captivate variables available to Captivate developers. I figured I should document them for future reference. Note that some variables available in CP3 and CP4 are no longer available. The following list should be exhaustive for CP5;
By popular demand, I’ve updated my CaptivateController to work with Adobe Captivate 5 (CP5). Since this is an open-source project, there’s no upgrade fee. (What? “Adobe” and “no upgrade fee” in the same paragraph?!) I kid, I kid… I’m a kidder. As you may have heard, Adobe
If you spend any time using Adobe Captivate to create SCORM-conformant courses, you’re bound to have run into an issue or two that caused you to read some Captivate forum posts. Almost without fail, someone will mention that the solution to their problem was changing the value of the
SCORM courses use JavaScript to send data to the LMS. This data then sits in the browser until the LMS writes it to the database (usually via AJAX or form posts). As previously discussed, invoking commit (save) will ensure the LMS actually writes this data to a database. But what