I'm trying to develop a custom Interactive Widget. This widget will allow the user to take multiple attempts, and needs to store information about previously completed attempts so they can (hopefully) see their improvements over time.
I'm trying to figure out the best way to store the data about the previously completed attempts across multiple sessions in a LMS. It seems that the data stored in user variables is automatically stored/restored in suspend_data, which would be perfect. The issue is that I can't find a way to dynamically create a new user variable from within a Widget. It looks like I can only access user variables that the author has explicitly defined in the Captivate interface. I'd rather not have to force the author to define an empty User Variable that they'll never knowingly use, just to give the Widget a bucket to store its data.
Does anyone have any ideas for what might be the best way to accomplish this? I'd like to stick to standard, "approved" APIs as much as possible, but I'd be willing to bend some rules if necessary.
I'd love to know the answer to this as well. From what I can gather, the variables created at design time in the Cp UI are dynamically injected into the swf using the CaptivateMainTimeline.as file on swf publish.
I was afraid it was something like that, Jim. Do you have any advice or approaches to pull off something similar that have worked in the past?
I assume you've asked this question here:
I asked a similar question here:
Philip gave you sound advice. You'll have to hijack/re-purpose the comments or the suspend data. I was successful in using SCORM comments in a Moodle system to store extra data I needed for a customer. It's not ideal, but it gets the job done. Here's a thread about that:
If you use suspend data, you have to watch out for a few things:
1. It's base 64 encoded... so any data you append to what Captivate outputs will need to be in base 64 (that's a good practice anyway since the data has to be serialized).
2. On course re-entry, you'll need to capture the suspend data before it hits Cp to strip off / read your needed data. If the suspend data isn't in the format Cp expects, you'll get a nice white screen of death.
Ideally, it would be nice to be able to dynamically create user variables for purposes like this... and it's been requested in Cp 6.... we'll see if it gets added (not holding my breath). Until then, I'd use cmi.comments.
Yep, that was me! I just figured I'd check for a second opinion before I cut open the patient.
I had considered hijacking the suspend_data as you suggested, but as you also mentioned it seems like it could be pretty brittle.
Thanks for the advice. I'll give cmi.comments, and thanks for the heads up about Cp6!