When publishing for SCORM, Captivate does not use synchronous communication methods.* Depending on the browser, Captivate uses either FSCommand or the old-school getURL method to communicate with the HTML file; the HTML file then uses JavaScript to relay the data to the LMS via the SCORM API.

The response (if any) is relayed from JavaScript to either FSCommand or a proxy SWF (for getURL), which is then monitored internally in Captivate via a callback function. This callback function uses timers, and that s probably where your problem lies.

If you re setting g_intAPIType to 0, you re forcing the browser to use FSCommand, which isn t supported in all browsers and operating systems. Setting g_intAPIType to 1 means you re forcing the browser to use getURL, which is cross-browser but has a few drawbacks (including lots of clicking sounds).

In both cases, the data is sent via an internal queue script, which uses the waitForResponse callback function.

The performance problems you re encountering are likely due to the queuing, and the asynchronous communication compounds the problem because of timers attached to waitForResponse. Changing g_intAPIType will probably only have a minor effect on your performance issues, though using getURL (g_intAPIType=1) may help improve consistency from browser to browser.

Regardless of the g_intAPIType settings, you cannot prevent the internal tracking mechanism from using the asynchronous waitForResponse function, so there is no way to stop Captivate from using timers when getting/setting data; over a period of time you will probably start to notice longer and longer delays like the ones you described, esp. if you re making a lot of calls to the LMS.

(* Small exception: I ve been informed Captivate 4 and 5 use ExternalInterface if the project is built in AS3 and is published for SCORM 2004, but it appears the queue and waitForResponse timers are still used, basically treating ExternalInterface like the asynchronous methods listed above.)

Some Options:

You could change how you are doing the questions. Instead of 1 per frame put all the questions on 1 frame.

Otherwise, you will need to do some JavaScript magic in your SCORM Player JavaScript. I would start with minimizing the JS code with a tool like JSMin.

Then try to cache the JS files so they are only loaded once. I suspect that the files are being called over and over with each frame.

"There is a way to make this sync?? I mean, to force the flash wait some way?"

Apparently, the problem is this one : "Captivate is the only SCO that calls SCORM JavaScript functions asynchronously. Firefox is the only browser that does not force synchronous communications between the SCO and the supporting JavaScript. When a Captivate SCO, running on Firefox, submits a status update to one of the JS functions, Captivate does not wait for a success or fail response before submitting the next status update. Since Captivate is quite verbose in its communications and JavaScript is not multithreaded, quiz status submissions can stack up and overwrite each other. This can cause a loss of data - especially for longer quizzes. [...]

If you d like to see the asynchronous problem with any other LMS, take a long Captivate quiz using Firefox and answer the questions very quickly. Some of the questions near the end will get dropped.. " (interzoic.com forum)

And maybe a solution : "The slow issue is resolved when I force the g_intAPIType to 0 (into the .htm file), so it force Captivate to communicate as if it was into IE."

In captivate, while publishing a scorm you will see option "Send tracking data at the end", Use this option, it will resolve your problem.