Hi Artur, Does the module function normally most of the time and this only occurs occasionally? We have a workaround for when Lectora modules get 'stuck' in an API non-initialized state due to a disconnection or opening the module many times.
Normally though the 'go back to previous page' works for us though, so this may be a different problem if yours always does not work.
What version of Lectora are the modules created in?
Hi Matthew,
We are also experiencing this issue with Lectora SCORMS created with Inspire 11.3 and Moodle 2.5.3
Could you provide details of your workaround?
Thanks,
Kerry
Hi Kerry, we had to replace the scofunctions.js file in the Lectora installation directory, Support Files folder with a slightly tweaked version. This way it gets included in the SCORM package when it gets published. I attempted to get Lectora to implement this workaround in their releases but they would not, indicating that their scofunctions.js file comes from the reference ADL implementation.
The tweak is in the loadPage() function in scofunctions.js, replacing the line
if( startDate == 0 ) {with:
if( startDate == 0 || !LMSIsInitialized()) {The fix came from Dan Marsden and it's been happily working in our courses since February 2015, so I'm confident in it. The only issue is if you've already published the SCORM package, you will need to re-publish it again after changing the scofunction.js file in your Lectora install, or taking the SCORM module unzipping it, and replacing the scofunction.js file with the updated one and re-zipping. But you'll have to do that each time you publish it.
Thanks Mathew, This has worked for us.
Thanks Mathew. We tested this out and it looks like a great fix. It will be in the next release of Lectora.
Thanks Darin that's great!
can you please clarify what version of Lectora will contain the fix so that others reading this in future can resolve it in the same way?
Also - I wonder if there is any way we can work better in future so that things like this can be fixed a bit faster? - I wrote that patch for Lectora packages about 12 months ago (but I never personally got in touch with Trivantis)
- The technical details around this were....
The Lectora code expects "TrivantisSCORMTimer" to be set to 0 (or empty) when entering the SCORM package but as the cookie is maintained and not cleared or reset to 0 when exiting the package previously, any subsequent entry to the SCORM fails as LMSInitialize is not called first.
It appeared that in some browsers "TrivatisSCORMTimer" was still set after exiting a SCORM package - and I couldn't see any code in the package that would actually clear the var after the package was closed. Adding that line just worked-around the error although another fix would have been to track down why the var wasn't being cleared on exit of the package. I couldn't reproduce this on the SCORM Cloud but it's possible they detect the js call prior to LMSInitialize() and just manually trigger an LMSInitialize() call rather than getting too worried about following the spec formally.
thanks,
Hi Dan,
This is included in Lectora v16 Inspire and Publisher which is in the final stages of testing for release next month. I believe that it will also be in LO version 3.0.1 also coming out in the couple weeks.
One of the best ways to let us know about issues like this in the future is to report it to our support
1 866.852.6700 / http://trivantis.com/contact-support/.
Support has access to our product backlog and issues database and can pass this along to development.
Also, I would encourage you to join our forum at http://community.trivantis.com/. It is monitored and also feeds our backlog.
Cheers,
Darin
Thanks for providing the version details. I'm not sure that the support team is quite what I was looking for - particularly as I am not personally a Trivantis client. Great to see you engaging with us here in the forums though!
