Loading...

Blog

Captivate 7, Exit Bug and a Solution

Several of our Inquisiq R3 users have alerted us to the fact that courses developed with Captivate 7 published to HTML5 and SWF do not close properly when using the “Exit” button, forcing the user instead to manually close the browser window by clicking the “X” in the upper-right corner of the browser window.

Through our investigation into this issue, it appears that the process that Adobe has implemented when clicking the “Exit” button is to simply attempt to close the content window and rely on the LMS to capture and commit the session data. Nowhere did we see that the content was actually calling the “LMSFinish()” [SCORM 1.2] or “Terminate()” [SCORM 2004] methods in the LMS’s SCORM API to commit the lesson data to the LMS as required by the SCORM specification.

Adobe uses their own defined function, “DoCPExit,” to close a lesson window.  This method contains a “window.close()” call and additional logic to “bubble up” the command through the frame parents (if they exist and also contain the “DoCPExit” method – presumably because they would also be Adobe-published content files within your package).

There are several flaws to this approach.

  1. By not calling “LMSFinish()” or “Terminate(),” the content is, by definition, not SCORM conformant.  Part of the minimum requirements for conformance are that the content calls the initialization method “LMSInitialize()” in SCORM 1.2 or “Initialize()” in SCORM 2004 and the  termination method “LMSFinish()” in SCORM 1.2 or “Terminate()” in SCORM 2004. The LMS is not required to clean up the data left behind when the content fails to make this call. So if your LMS doesn’t take this additional step (of setting ‘LMSFinish’ or ‘Terminate’ if the lesson does not), your data will be completely lost…i.e. no record of you taking the lesson will be recorded.
  2. The call to close the browser window will fail if the LMS is running the content within a frame or iframe. Since the SCORM specification allows content to be launched in frames or iframes (in addition to new browser windows), lessons need to be able to accommodate this scenario. Even with the “bubble up” logic, once the call reaches the top most content window, and the next parent window in line is the LMS container page, the call will no longer be passed and a “window.close()” call will be fired within the framed page.  When this call is made, nothing will happen as a framed page cannot close the browser window using this command. Through our investigation, we’ve learned that at least 4 other well-known LMSs have experienced this particular issue.

 Ironically, the solution that we’ve discovered is not only SCORM conformant, but also very simple and follows what we would consider to be SCORM “best practices”.  The foundation and logic for the solution is already contained within the published Captivate files (and it is the same solution whether you publish to SCORM 1.2 or SCORM 2004).

We simply modify the “DoCPExit” method that is contained within the “Utilities.js” file to call the “Finish()” method.  Just replace all the code appearing between the “{“and the “}” as you see here:

function DoCPExit(){

   Finish();
}

The “Finish()” method that we have inserted is, as mentioned, already contained within the published Captivate files and contains the logic to properly set the exit parameters and correctly identify whether the content is SCORM 1.2 or SCORM 2004; it will therefore make a call to the correct close method (“LMSFinish()” or “Terminate()”) accordingly.  Once the LMS has received this command, it should take care of removing the content properly, leaving no need for any “bubble-up” logic or window close calls within the content code.

Overall, if the lessons you develop with Captivate 7 work as expected and required in your LMS, there is no need to implement this change. However, if your lesson’s Exit button is not working as it should, and/or you are losing progress and status data when closing the lesson, the fix described here should resolve all those issues.

The biggest issue here is that since we’re changing published code, the next time you update and publish that same Captivate project, you have to remember to change that published function code AGAIN, as Captivate will simply publish the default code.

We have been in touch with the Captivate team to discuss this problem and they are investigating. We would hope a patch to address this flaw would be released in the near future.