This document describes my experience using Adobe Captivate to generate a SCORM 1.2 content package. This includes the verification of such a package using the ADL test suite.
Using captivate I created a set of multiple choice questions – I won’t go into all the details of how to do this as it was the easy bit! Export the package as a SCORM 1.2 zip file.
The details of this fix have been borrowed, then embellished, from http://www.mylearning.be/2009/09/adobe-captivate-and-the-adl-scorm-test-suite-1-2-7/
To make sure that your SCO gets launched in the test suite, you need to edit the html file that is generated by Captivate when publishing your content (the .html that has the same name as your project .swf). Open the file with a text editor (Notepad), on the second line you will find <!– saved from url=(0013)about:internet –>. Delete that line.
Restart your test, and your SCO will now launch. But you will get errors in your test now. Fix number two: change the security settings of the Flash player on your machine.
- Get some Flash content playing in your browser. Any Flash animation will do. Go e.g. to www.adobe.com.
- Right-click on the animation, you will get the Flash context menu. Select Settings.
- You will get a little menu like this:
- Click the Advanced button. This will bring you to an Adobe Web site.
- In the table of contents on the left, click Global Security Settings Panel. This will show you a panel like this:
- Add the location where your ADL TestSuite software is installed to the trusted locations. The location of the TEST SUITE software, not the location of your zip file or your content files. Those get copied automatically to a TestSuite subfolder when you run the test.
- Close all your browser windows and re-run the test.
From here, I continue the explanation with my own experience … having unzipped the original zip file to make changes to the HTML file I decided to test with it unzipped as the test suite has that option – do not do this. I wasted a great deal of time trying to work out why LMSInitialize() was not being called by my content, to the extent that I actually hardcoded a change in to make sure it was called. This unzipped package now passed the test suite, but having never run anything through the test suite before I couldn’t tell if it was working correctly.
Everything now works, hurrah, so I rezip the package and decide to give it a final test. LMSInitialize() now gets called twice, hence the waste of all my effort – I then removed my hardcoded call. Now, when you run this package through the test suite, not only does it pass, but it shows you all the data communicated from the content package to the LMS (getValue/setValue calls).
In summary, the only thing wrong with the initial Captivate output is that it contains a comment (on line 2) that needs to be removed. I suspect the other fix is only needed to satisfy the test suite running the package from the local disk, as opposed to being served through a web server over HTTP.