Content about how to troubleshoot issues in Adobe Captivate.
After you insert an object into a Captivate project file, there is often a need to update the object with a newer version. Some objects are easier to update than others.
For example, let’s say you insert an image or sound file into a Captivate project and then later make changes to the original image or audio file at it’s location on your hard drive, outside Captivate.
You could of course just delete the original object in the project file and insert the newer version in its place. But this might mean a lot more work to reconfigure its size, position, applied effects, etc.
Updating from the Library
When you want to update the same file sitting inside your Captivate CPTX, all you need to do is right-click the file in the Library and choose Update from the context menu (as shown in the screenshot here).
This will open an Update Library Items dialog that shows the name of the file you are updating with an Update button at the bottom of the dialog that allows you to overwrite the file currently sitting in the Library with the newer version on your hard drive.
Captivate will do a quick check to make sure the original file is still at the same folder address and whether the version it has in the Library is older. But the process is relatively simple and, unless you have moved the original file or do not have access to it, your update should only take a few moments to complete.
The important thing to remember here is that there isn’t any change to the filename when updating. But that isn’t necessarily the case for all objects.
How to update OAM files
If you have ever used OAM files in Adobe Captivate, you may have discovered that updating these objectsseem to be more difficult than with other types. In fact, even if you try to use the normal Update method explained above, you may see no changes to the OAM content in your published output.
The reason seems to be that OAMs inside a CPTX project file cannot be overwritten by another OAMif it has exactly the same file name. So, the trick here is to simply change the name of the newer OAM before you try to use it to overwrite the one inside the CPTX.
Change the filename of the newer OAM
When I am building content that uses OAMs for animations and interactions, there are always lots of changes to the content before go-live. So my workflow is to name each publish version of the OAM with today’s date and a letter of the alphabet after it to ensure each published version is unique.
For example, MyOAM_20200618a for the first version I publish today, then MyOAM_20200618b, MyOAM_20200618c, etc.
The Web Properties dialog
OAMs also use a slightly different updating method. You still need to find the item in the Library. But this time just double-click the OAM file to open a Web Properties dialog (like the one in the screenshot here).
Click the Import… button, navigate to your new OAM version at its current location and select it. The new OAM will then overwrite the older OAM and replace all instances of it on any slides in the project where it has been added.
Topics to help troubleshoot those annoying issues Adobe Captivate developers often encounter. All information in this section of our website was originally published in PDF e-book form and is now made available as web pages.
If you’re an Adobe Captivate e-learning developer, it is now most likely that you will be delivering your e-learning courses via some kind of Learning Management System (LMS for short). If so, you may encounter an issue where course participants complain about the content “freezing up” or pausing repeatedly during playback.
This issue is usually caused by LMS server latency. In mild cases it can just be annoying. In serious cases it can completely cripple the effective delivery of your e-learning project.
As mentioned in the above-mentioned post explaining LMS server latency, the greater the number of separate files there are in your course, the more requests will be sent to your LMS server to download them. An HTML5 course published from Adobe Captivate is actually made up of hundreds (potentially thousands) of smallish files, all of which need to be requested from the server. But since HTML5 is now more or less the only viable Adobe Captivate publishing option for web delivery you should at least reduce the number of file requests by minimizing the number of images, and other small objects in the course content. For example, rather than having a large number of separate images on a slide to create a complex background, how about just assembling these images in a graphics editor as a single graphic file and use that as a slide background instead?
Minimize data requests by modifying Quiz Settings
If you’re suffering with serious LMS server latency issues, the number of files in your ourse is not likely to be the biggest culprit. You should probably be looking at reducing the number of data requests. Server latency issues often turn out to be related to the number of times your Captivate content is pinging the LMS server to tell it about the course participant’s interaction with the content.
So what can you do about that? Fortunately quite a bit!
For the purpose of this discussion we’re assuming you’re using a SCORM-compliant LMS because this gives you the largest number of options for reducing server load. (Choosing any of the non-SCORM reporting solutions in Captivate cuts out most of the options we discuss below.)
All of the options that allow you to reduce LMS server load are found on the Quiz > Reporting dialog. We’ll start at the top of the dialog and work our way down, discussing each option you can use.
Use the SendTrackingDataAtEnd Template
When you choose SCORM as your LMS standard, Captivate assigns a default template full of code designed to communicate with the LMS. However, the default template uses Captivate’s normal ‘verbose’ communication method, which deluges the LMS with tons of information.
However, you can opt to use a different Template by selecting one from the dropdown list. The best one for reducing LMS load is called SendTrackingDataAtEnd.
How is this template better? Well, instead of sending tracking data to the LMS all the time while the participant is interacting with your course, this template stores the information and only sends it to the LMS when the user exits the course module. That means one request to the server instead of dozens.
This single change is likely to have the biggest positive impact on server latency issues. If you want to test whether or not changes to your content will fix your server latency issue, perform this one change and test the output on your server. If this has little noticeable impact, I doubt whether any of the other changes below will make a difference either. Your server is probably toast.
(By the way, if you have experienced SCORM programmers on your staff, you also have the option of creating a custom template and adding this to the relevant sub folder in the Templates folder of the Captivate install directory under Program Files. But don’t attempt this unless you or your programmer really know what you’re doing.)
Report quiz results only, not slide views
Let’s be honest. How often do you really need to track what percentage of the slides were viewed by the course participant? In most courses the key result that everyone is interested in is whether or not the participant passed or failed the quiz.
So, unless you have a compelling requirement to track slide views, I recommend you turn off this option by deselecting the relevant Slide Views boxes on the Quiz Preferences screen as shown in the example screenshot below.
Since the number of content slides in a module usually far outnumber the quiz slides, not tracking slide visits will further reduce the data sent to the LMS server.
Don’t report Interaction Data
Further down on the Quiz Reporting dialog you will find the section that determines Data to Report to the LMS. This option is selected by default. Deselect it, as shown below, to further reduce load on the server.
This dialog is reached via buttons near the bottom of the Quiz > Reporting dialog. Just look for the Advanced button (as shown in the screenshot above) and when clicked it opens a dialog like the one of those shown below.
As noted below each screenshot, there are slightly different options depending on whether you select SCORM 1.2 or SCORM 2004. However, regardless of that difference, the two important options here for reducing server load are:
Send Data On Every Slide – Ensure this option is deselectedto prevent Captivate from pinging the LMS every time the user advances from one slide to another.
Never Send Resume Data – This option is deselected by default. So, you need to selectit to preventCaptivate from sending data to the LMS about which slide the participant is currently on. (Resume Data allows the LMS to ‘bookmark’ the specific slide the course participant was viewing at the time they exited the module as well as grab any data about their quiz question answers and score. When the user later resumes their session this data is fed back to the module so that everything looks the same as when they left off. So, selecting this option to “never send resume data” effectively disables LMS bookmarking. Bookmarking the user’s progress in a course module is usually regarded as a good thing. So, you would only choose to disable it if bookmarking was deemed far less important than reducing your server latency.)
Which countermeasures should you use?
Well that depends entirely on how bad your server latency issue happens to be. Only you and your IT department are really able to answer that question. If you’re not currently suffering with noticeable server latency issues (as indicated by course participants complaining about the content freezing up for no apparent reason), you probably won’t need to enact any of the countermeasures outlined above.
Another factor to weigh up is that all configuration options in Captivate have advantages and disadvantages. Each thing you turn on or off will have an impact somewhere else in your content. For example, if your e-learning modules are quite long and most users do not complete them in a single session, having Resume Data bookmarking might be deemed more essential than the small amount of extra server load it imposes.
So, you need to weigh the pros and cons before making a final decision. And the only way to evaluate the pros and cons is by making changes and then testing to verify the resulting differences in server load.
Last resort: Upgrade your server technology!
At the end of the day, if your server technology is outdated or inadequate, none of the measures suggested above may ever be enough to fix “the issue”. You could end up just chasing your tail spending hours, days or weeks modifying your courses when the best solution might simply be to lobby your management for budget to buy the level of hardware infrastructure your organization really needs to cope with the amount of learning you need to deliver over the next 5-10 years.
Though thankfully a relatively rare event, Captivate projects have been known to suffer corruption. If damage is severe enough, a corrupted file will simply refuse to open in Captivate and then you need to resort to one of the methods suggested in this section to recover it.
If you are unable to recover the project, and you didn’t take the extra precaution of doing daily backups, then you are in all likelihood going to lose all your work on that file.
Why Captivate projects sometimes corrupt
It’s important to remember that Adobe Captivate is actually a very complex application. Any software developer knows that the more complex an application becomes, the more likely it is to contain annoying bugs, and the more likely that you will at times encounter a condition from which the application cannot recover, resulting in a ‘crash’. Some Captivate versions (and updates) have certainly had ‘teething problems’ and critical stability issues, which Adobe usually addresses quite quickly. (By contrast Adobe is far less likely to address other equally annoying usability issues because these do not cause the app to crash and lose work.)
The more recent versions of the app and its file format seem to have be very stable. In my personal experience, when Captivate is properly set up on the developer’s system, and used in accord with best practices, it is extremely stable
Here are some of the reasons for the occasional instability issues that some Captivate users experience:
The nature of the CPTX file format – A CPTX project file is actually a zip archive in disguise and may contain hundreds or even thousands of smaller files relating to the myriad of objects, images, and actions contained in your e-learning course. Each of these tiny files must be flawlessly saved back to the default location of the Captivate project cache folder every time you perform a save action. If for any reason this save action does not occur as planned, corruption may result. This is a key reason why Captivate developers are told NOT to directly open CPTX project files residing on a network or cloud drive and NEVER to save changes directly back to the same network or cloud location. See the next item…
Working on project files over a network – Another big cause of project file corruption in Captivate is the ill-advised practice of storing project files on a network drive and using Cp to directly access and work on these files over the network. All it takes is the smallest glitch in network traffic at the same moment your file is being saved to render it beyond repair. This is why Captivate authors are repeatedly advised to maintain all currently active project files in a folder on your PC hard drive rather than on a LAN.
The project file is not corrupt, but some objects within it may be – We just mentioned that a Captivate project file is actually a collection of scores, hundreds, or even thousands of objects. Sometimes one or more objects conflict with others and this manifests itself similarly to project corruption. One way this can sometimes occur is due to developers doing too many copy / paste actions from one project to another. Captivate will normally rename any objects being copied, so as to avoid the possibility of two objects ending up with the same unique ID. But it’s still best not to tempt fate. Image files (e.g. SVGs) and fonts are two areas that often turn out to be corrupted. Any third-party components such as OAM files should also be considered as possible sources of corruption, especially if they were not created by compatible apps made by Adobe.
The current IT love affair with virtualization technologies – In recent years we are seeing a growing trend for corporations to employ new technologies known as virtualization. This approach is designed to make it easier to maintain the company’s valuable information assets by ensuring they are all located on central servers rather than being spread all over the landscape on individual PC drives. This means that user profiles, desktops, and My Documents folders are now often stored on servers to facilitate easier management and backups. Unfortunately for Captivate users, this innovative IT management approach has some major downsides, one of which is that it requires files be remotely stored and not locally on the developer’s own local drive. As stated earlier, this can sometimes cause Captivate to become unstable and crash, which can then result in project file corruption. If you work in a corporate environment where virtualization and roaming user profiles are the order of the day, you need to explain to your IT people that working from anywhere other than the hard drive is a known cause of file corruption and ruined projects with Adobe Captivate. Hopefully they will do a quick search on the Adobe Captivate Forums to verify your story. They should be able to locate large numbers of users complaining about lost projects due to working over a LAN instead of locally.
Unable to open a specific Captivate project file
One day you try to open a Captivate project file you’ve been working on, and all you get is some kind of cryptic error message. Here are the most likely reasons:
Project lock file still present in folder
When you open a project file for editing, Captivate creates another hidden file with the same name, but with a cptx_lock file ending. This file locks your project to prevent any other user from attempting to edit the same file while you have it open.
This file is normally deleted to unlock the project when you save and close. However, if Captivate crashes or the lock file is not deleted on closing the project, then you project may remain locked from the previous editing session.
Browse to the file location and see if there is a file with the same name but with a cptx_lock file ending as shown above. (The lock file is a hidden file. So you need to Show Hidden Files and Folders in Windows folder settings.) If you find the lock file, delete it and try to open the project again from within Captivate.
Project file has become corrupted
If you still cannot open the project file, it may have become corrupted during the last editing session, or when you saved it. You may be looking at a case of corruption if you see any of the following symptoms:
Captivate opens without issue but crashes as soon as you open the project file. (You can prove this must be due to the project file itself rather than Captivate because it opened initially and other similar projects open without issue.)
The project crashes or throws error messages when you attempt to publish out.
After publishing, some part of the project fails to work or shows blank slides.
Captivate refuses to open the project file at all, even though the same project worked perfectly the last time you opened it.
The most common reason for project file corruption is NOT following the rule to ONLY work on projects stored on your local hard drive. In mild cases, you can often use a process of elimination to locate and remove corrupt slides, objects, or actions thereby restoring the project to full functionality. In worst-case scenarios, you may need to restore an entire project to an earlier point in time in order to resurrect it. That’s only possible via backups or by using the cache.
If you obey the instructions on this website about setting the Captivate Project Preference to Generate Project Backup, then all you need to do is go to the folder containing the project file, delete the .bak file ending from the backup file, and open it in Captivate. All you will lose this way is any work performed since you last saved and closed the project file.
If you have not as yet cleared your Project Cache, then you can often resurrect a project all the way up to the last Save action by converting the cache files back into a CPTX file. see the instructions in the heading below about how to recover a project file from the cache.
Locate and remove corrupted elements from a project
Corruption is usually limited to one or more slides. Sometimes the issue can be caused by a single object on one of the slides. If you can locate and remove the corrupting elements, you can usually restore your project to full functionality. If fortune smiles and you can still open and navigate the project, try using a process of elimination to locate the offending slide or object and remove it.
Hide all slides in the first half of your project and try to publish again.
If you still cannot publish, hide all slides in the last half of the project and try to publish.
If you are able to identify the half of the project where the corruption exists, use the same slide hiding process to progressively narrow down where the problem slide is.
Once you identify the issue, remove the object or slide and try publishing again.
The good news is that even if your Captivate project file does turn out to be completely corrupted, if you followed all the suggestions in the section of this document about setting up for Captivate development, you still have at least two options left.
Recover a project from backup
If you implement the suggestion to Generate Project Backup in Preferences, then you will start seeing duplicates of your project files appear in the same folder with .cptx.bak file endings. This is really just a copy of your current project file that contains all changes up until the last time you saved and closed your project.
Just rename or delete your corrupted project file (so that you’ll know which one it was) and move it out of the way somewhere.
Next, remove the .bak ending from the backup file and try to open it in Captivate. If your backup file predates the moment when corruption afflicted your project, then it should open properly and you’re back in business. You will of course lose all work performed after that file was lasted saved and closed, but at least you’ll still have a working project file.
Recover a project from cache
Your backup file can only ever contain changes you made up until the last time you successfully saved and closed down your project. If you want to try and recover all changes to the current state of your project, you can try restoring from the cache. This is a special folder where temporary working files are stored as you edit a Captivate project file. The default location is usually in My Documents > Adobe Captivate Cached Projects. However, on corporate networks user profiles are often virtualized, which means the user’s My Documents folder is not located on their local hard drive but resides on a network or cloud server somewhere. So, I usually advise Captivate developers to set up a special folder near the root level of their local C: drive so that the project cache has no chance of being corrupted.
To change the Project Cache folder location, open Edit > Preferences > General Settings > Default Locations > Project Cache and use the Browse button to navigate to the special folder you set up for this purpose. As you can see from my example below, the folder I set up is right at the root level of my C drive.
If you’ve been working on quite a few project files your cache will likely contain a large number of folders with names that consist of seemingly random letters and numbers. These folders contain all the files necessary to recreate each separate project file you’ve worked on since the last time the cache was cleared. The contents of the cache folder are updated each time you hit Save for that particular project. This means, if you know what to do, you can sometimes resurrect a project file that steadfastly refuses to open via any other method. This is great news for Captivate developers!
But it’s not all good. Since the folders all have this cryptic naming convention, it’s impossible to tell from just looking at the names which specific project each one contains. If you run into project corruption issues during a particular session, you can sort the project folders by date modified and that should shorten the odds somewhat. The most recently modified folder is probably the one for your project.
Using the Dcache application
However, what if you are trying to resurrect a project file from last week or last month? By now you may have opened and worked on dozens of projects and finding the right one in the cache is like finding a needle in a digital haystack.
Adobe realized this would be the case and created a special AIR application called Dcache. You can download the free Dcache utility from here. This application enables you to browse those cryptic cache folders and see which one relates to a given project. However, be warned that AIR apps are actually encapsulated Flash files programmed in ActionScript 3. So, it’s very possible that your system may no longer allow you to install or use these files due to the much advertised “Death of Flash” at the end of 2020.
Assuming you still can use the Dcache AIR app, once you locate the correct cache folder for your problematic project, just browse to that folder in windows explorer and open the single db folder it contains to see the files and folders shown in the screenshot below. Now you’re ready to recover the project as per the following instructions.
To recover a project from within the cache db folder:
Select all files and folders EXCEPT any called already_in_use.lock or backup_data. (Including these files would prevent Captivate from opening the recovered project once you convert it back to a CPTX.)
Right click on the selected group of files and choose Winzip > Add to db.zip from the context menu. (This assumes you’re one of the 99% of users that have Winzip or some similar compression app.)
Save this zip file to another location (usually where you store your project files) and change the file extension from .zip to .cptx.
If the project file opens successfully, you will see all saved changes up to the point the development session was closed or Captivate became unresponsive and crashed. If the recovered project file will NOT open, you may yet be able to find an older cached version of it that is still recoverable. However, if you’ve already cleaned out your cache, those versions will not exist anymore.
So, all things considered, Adobe has tried to support you by providing a backup file option in Preferences, cached project versions you can use as a last resort to restore the project, and even a free utility to browse the cache and identify specific projects you may want to recover. But, in some cases none of this is going to be enough and you will in the end lose work due to corrupted projects.
Life wasn’t meant to be easy…
This section of the Infosemantics website provides information resources we have created for Adobe Captivate e-learning developers. This includes tutorials and blog posts, training courses, and troubleshooting tips. Links have been grouped under categories to make it easier to locate information about specific topics. Each topic area can also be reached separately via the submenu links available under the Cp Knowledgebase main menu link.
PLEASE NOTE: Some information is free to view, while other information may only be available to paid subscribers.
Adobe Captivate Basics
Adobe Captivate Troubleshooting
Advanced Actions and Variables
SCORM and LMS Integration
E-learning Instructional Design
Nothing much to show here at the moment, but stay tuned, we’re working on it!
Before you begin developing in earnest using Captivate’s Variables and Advanced Actions to enhance the interactivity of your Captivate content, I recommend you take a few minutes to set up a debugging environment. Doing so can potentially save you many hours of frustration wondering why your carefully-crafted interactions are not working as you expected.
There are a number of ways you can achieve this, but in the example below I use Smart Shape Buttons because they can be timed to display for Rest of Project and are therefore available for view on any slide after the point where they are inserted.
How to set up a DEBUG slide in Captivate
First we need to insert a Smart Shape timed to display for Rest of Project. This shape displays values of any important User Variables you need to check at some point. We use a Conditional Action (triggered by other Smart Shape Buttons) to toggle the visibility of this shape when it needs to be seen.
Insert a new slide near the beginning of your project file or project template, but not as the very first slide. (Having too much complexity on the very first slide of a Captivate project is never a good idea because too much is happening in the background as that slide is loading.) Use graphics and captions to clearly indicate this slide is a debugging slide.
Create a User Variable called DEBUG_MODE_ON, set to 0 by default, and another called DEBUG_MODE_INDICATOR_TEXT which contains whatever text you want to have showing as the label of the toggle button used to Show or Hide your debug variables. I set mine with a default value of DEBUG IS OFF.
Insert another Smart Shape and select the option in Properties tab to Use as button so that it becomes a Smart Shape Button. Set the button timing to display for Rest of Project. You’ll need to make this button reasonably small and place it in an area at the top or bottom of the slide so that it will not end up in the way of other controls when testing the content at run-time but can still be easily clicked.
Double-click this Smart Shape Button to add text and from the Properties tab, click the Insert Variable button. When the Insert Variable dialog appears, select the DEBUG_MODE_INDICATOR_TEXT variable from the User Variable list and click OK. This variable’s current value will now be displayed as the button label. We will be changing the value of this variable later when the debug display is being toggled on and off.
Insert a second Smart Shape and resize it to cover most of the slide but place it so that it does not cover your toggle button shape. This object displays any user variables you want to view at run-time. So add some explanatory text at the top to make it obvious.
Both Smart Shapes should be situated at the very top of the layers on the DEBUG slide, and both should be set to display for Rest of Project. Only one is set to Use as Button. To make these objects easier to find, give them meaningful Item Names (as shown below).
Now we need to create the conditional action that will toggle the visibility of the Smart Shape displaying your user variables. That conditional action looks like this:
Test the functionality of the debug slide by clicking the Smart Shape button that triggers the Conditional Action to Show or Hide the Smart Shape that displays variable values. If clicking the button shows and hides the shape as intended, so far so good. The label text in the button should change from DEBUG IS OFF when the variables are hidden, to DEBUG IS ON when they are visible.
Although your debug slide is ready for use, you may want to simply Hide it in the filmstrip until you actually need it. Hiding a slide prevents it from being published in the output. You definitely will NOT want this slide to become visible to your end users when the project eventually goes live. So, be sure to hide the slide again before the final publishing of your course content for delivery.
How DEBUG MODE works
Now that you have everything setup, if you encounter any issues with Captivate’s interactivity, just go to the debug slide and into the large Smart Shape there (not the button) insert all variables that are related to the problematic functionality. This would especially include any variables that are directly referenced by Conditional Actions, or that are dynamically assigned values by other Actions, Advanced Actions or Shared Actions.
Then unhide the DEBUG slide, preview your project as HTML or else publish to HTML5, and click the debug Smart Shape button to toggle the visibility of the other Smart Shape that displays the debugging variables.
When you have finished debugging, just hide your DEBUG slide again to turn off DEBUG MODE and immediately disable your debugging environment. That’s all there is to it!
In most cases what you will find is that some variable is not changing to the value you expected and that is why things are not working properly. In my experience faulty logic in Conditional Actions is the usual reason for unexpected interaction behaviour. The big gotcha for many newbie Captivate developers is that all decision blocks in a Conditional Action get executed, not just the one where the condition evaluates to true. The order of the decisions is particularly important because a later decision may be changing the value of a variable that was correctly assigned by an earlier decision block. So, make sure you correctly understand how these work in Captivate. You can spend many fruitless hours debugging these things unless you can expose the values of the variables.
Can’t fit all your variables in one shape? Use two, or three!
One caption is usually sufficient to display all variables you need to monitor. However, you can add more captions to the debug slide if needed. Just place the rollover areas or toggle buttons side by side at the top of the slide so that you can call up each relevant caption or shape.
Add debugging to your project templates!
Since I started using this approach I’ve found it so useful when creating complex interactivity in Captivate that I now have this debugging environment built into any project templates I set up when working with clients for whom I create courseware.
In a previous (teenage) life I worked as a technician repairing and servicing domestic electrical appliances. It was there I first learned how to troubleshoot technical issues. Most of the time it just boils down to eliminating all possible causes until you find the one/s causing the issue. It’s not rocket science; just a process of elimination. After a while the diagnostic process speeds up because you learn to look for the most of the common causes first and eventually you will even know instantly what the problem will be as soon as you hear the telltale symptoms.
Similarly, some basic troubleshooting tips apply to just about any Captivate issue you need to debug. In the thousands of posts I’ve logged on the Adobe Captivate Forum I often find myself following the same diagnostic process of elimination I used when fixing washing machines and refrigerators back in my teens. This section gives you a quick apprenticeship in Captivate troubleshooting techniques that every Captivate user should know about.
Easy Troubleshooting Techniques
These tips cost nothing to implement, in most cases take moments to perform, and have “saved my bacon” more times than I can count.
1. Start with the most likely causes
Of all the possible causes for an issue, there is usually one that stands out as most likely. Start with this one and work down through the list of possible causes from most likely to the most unlikely ones. Don’t waste time initially exploring things that rarely turn out to be the cause if you know of more likely reasons that can be checked first.
2. Try to replicate the issue in a new project file
If you’ve been working on an issue that defies explanation, try creating a brand new Captivate project file and see if you can replicate the issue there. Sometimes you’ll find that a new project does NOT suffer the same issue. You can then stop blaming Captivate itself and start scrutinising the specific project file, which may have become corrupted in some way. If the project has become corrupted, the following two headings suggest ways to locate and eliminate possible causes of the corruption.
3. Simplify the project to isolate the issue
Very often a user will be unable to debug some baffling issue in a big complex project…simply because it is a big complex project. The larger the number of slides and components, the harder it becomes to know where an issue might be lurking. If you cut out the complexity, the issue may be easier to discern and thereby become easier to debug.
For example, when you publish a project, any hidden slides and their associated objects do not get published in the final output.
So a common debugging trick is to make a copy of a problematic project (thus keeping the original in case you make unforeseen changes to the project file that render it unusable) and then hide or delete half the slides to see if this resolves the issue. If hiding half the slides resolves the issue, then the cause of the issue was likely to be located somewhere in that hidden half of the project. Then you concentrate on that suspect half of the project and hide or delete half of it again.
Using this simple process of elimination you can often narrow down the problem to a specific slide. Once you have isolated the problem slide, the next step is to find which object (or objects) on that slide cause the problem. So, you can either just start deleting objects from the slide, or drag objects out into the scrap area so that they are still available but don’t get published in final output. In this way you can locate any object or group of objects that might be causing the issue. It’s the same process of elimination, but at the object level instead of the slide level.
4. Copy and paste slides to reset object IDs
Each object in a Captivate CPTX file is supposed to have a unique identifier. If for any reason multiple objects end up with the same identifier this can cause corruption.
One way to resolve the issue is by copying entire slides from one project to another. This forces Captivate to assign new unique Item Names to all copied objects. If the corruption was caused by conflicting identifiers, this will sometimes fix the issue, and it takes only a few moments to test.
5. Don’t just partial Preview. Publish completely!
I wish I had a dollar for every question where someone on the forum has been expressing frustration with Captivate because something is not working as expected and it turned out they were hitting F10 and previewing only the next few slides, and not publishing the entire project.
Similarly, the basic Play Slide (or F3) preview will only play the slide timeline of the slide you are currently viewing in EDIT mode. And this won’t show you how everything will look at runtime, especially if you have Effects on any objects. The issue here is that some functionality will ONLY work properly if you publish the project completely.
For example, click boxes or buttons set to Jump to Slide will ONLY work if you publish completely or use F12 to Preview In Web Browser. So if something isn’t working, but you’re only partially previewing, try publishing completely.
6. Clear out your project cache
The Adobe Captivate CPTX file format makes heavy use of XML technologies and dynamic caching. In fact the CPTX file itself is actually a renamed ZIP archive that takes all the graphics, text and data that make up your project and packages it into a conveniently compressed format. If you don’t believe me, just take a copy of one of your CPTX files, rename it to a ZIP file, and then extract it to somewhere on your computer so that you can inspect the files and folders inside.
But there’s also another benefit of this approach. When Captivate is first installed on a computer, a special folder called Adobe Captivate Cached Projects is created inside the user’s My Documents folder. Captivate uses this Project Cache to store data while working on project files. The cache is essentially a ‘working folder’ that holds any changes to objects in the project until everything can be packaged up again in the compressed CPTX file when the project is finally saved and closed. The cache also helps to speed up publishing times for Captivate projects.
The default location of the cache folder can be changed in the Captivate Preference settings. It is actually highly recommended to change the location from your My Documents folder to another folder specially created for this purpose so as to avoid performance issues on systems where user profiles are virtualized and stored on LAN drives rather than on the user’s local hard drive. (See this page regarding recommended Preference setup.)
However, the Captivate project cache is not without potential problems. If after working on several projects you happen to take a look inside the cache folder, you’ll find that it maintains separate folders for each Captivate project edited, and inside these folders are zillions of small files that control every aspect of every object in each project.
Where this becomes a problem is that the cache folder can eventually accumulate several gigabytes of files and cause Captivate to become unstable. The solution is to do some ‘housekeeping’ and clean out the cache from time to time. There’s a Clear Cache button in the Preferences screen for this purpose.
Adobe recommends you clear your cache folder after completing each project and before you begin the next one. I tend to feel that it’s not necessarily a good idea to jump in too early and delete all folders in the cache because the cache folders can also be used to resurrect entire CPTX project files if for any reason your main project file is lost or becomes corrupted. So, I prefer to clean out the cache once I am sure there is no chance I might need those folders as a backup.
WARNING! Never use Windows Explorer or the MAC Finder tool to delete the files in the cache folder while Captivate is still open or you may crash the program. The recommended method is to always use the Clear Cache button under Edit > Preferences > General section.
7. Reset Captivate preferences
One of the most common ‘fixes’ for a wide array of issues entails renaming or deleting a specific hidden folder buried deep within your user profile. This folder happens to be the one that stores all of the Captivate data relevant to the options you select under Preferences and Workspaces. Unfortunately, if for any reason you are forced (or choose) to ignore recommendations about Captivate’s setup, then this preference data can end up becoming corrupted, leading to a wide variety of issues.
When that happens, the quickest solution is to either reset or delete the Preference folder, forcing Captivate to create a new default set of preferences the next time the app is launched.
The Preferences folder is not named ‘Preferences’!
It would be wonderful if the Captivate preferences folder was easy to find on your computer, but it is not. In fact, it is buried deep down inside your user profile and that means it is deliberately hidden by default so that it cannot be accidentally deleted. Even when you do finally locate the folder, it’s not named ‘Preferences’, but instead is named after the specific installed version of Captivate (because each separate version needs to be able to maintain different preference settings).
Do it the easy way: Use the CleanPreferences files
All current Captivate versions provides a very simple and effective way to reset preferences via special files buried in the Utils folder of your Captivate install directory under Program Files.
For example, on a 64bit Windows 10 system with Captivate 2019 installed, the files you need to use are found here:
All you have to do is close down Captivate and execute (i.e. double-click) the relevant CleanPreference file at this location to reset your preferences folder in a matter of a second or two.
Some users that experience preference corruption issues often even set up a custom shortcut on their desktop so that they can execute a reset at any time without even navigating down to the Utils directory.
Do it the hard way: Find and Delete the Preference folder
As noted above, the easy way to reset Preferences is by using the CleanPreferences files Adobe provides. However, if you happen to be working in a corporate office environment with a ‘locked-down’ operating system, you may not have the necessary Administrator permissions required to enter the Program Files directory and execute the reset. If this is the case, and your IT department is also unwilling to even set up the convenient desktop shortcut that would give you the ability to do this yourself, then your only solution for a corrupted Preference issue might be to find and delete the preference folder itsel.
To find the elusive Preferences folder, here’s what you need to do:
Show all hidden files and folders – Files in your PC user profile are normally hidden from view to prevent you from inadvertently deleting something essential, thus rendering you incapable of logging into your own computer. So, in order to locate the Captivate Preferences folder you need to make a change to default system settings and show these hidden files or folders. If your PC is not already set up this way, we cover this step in more detail in the section elsewhere on this website that discusses how to set up your computer to work with Captivate.
Close down Captivate – You cannot rename or delete the Preferences folder while Captivate is currently open. So, close down Captivate before performing the next steps.
Navigate to the Preferences folder in your user profile – Your user profile path to the folder will vary depending on your specific computer operating system. (In paths shown below for Captivate 2019, replace [user] with your own profile name.)
Apple MAC: /Users/[user]/Library/Preferences/Captivate [version#]
Rename or delete the preferences folder – As mentioned above, the preferences folder is not conveniently named ‘preferences’. In the example paths above, the Captivate [version#] folder is the preferences folder.
Once you’ve found the correct folder, all you need to do now is delete it, or just rename it to something else (e.g. add OLD to the end of the name).
Then, when you re-launch Captivate, it will detect that the preferences folder is missing and create a nice fresh (uncorrupted) new one for you. If your original issue was due to corrupted preferences, then it should now be resolved. (If it’s not resolved, at least you’re one step closer to finding the real reason.)
Please be aware that killing the preferences file, as described above, will mean you lose any customizations you may have made to preferences or workspaces when Captivate defaults back to original installation settings. But that’s usually a small price to pay for getting back a fully functional working app that enables you to meet that looming deadline.
8. Step away from the issue!
If you’ve been banging your head against some issue for hours without success, sometimes the best thing you can do is to walk away from it and do something else for a while. You may have become so close to the issue that you cannot see the solution staring you in the face. When I get stuck on a problem, I like to play my guitar, go for a walk, go for a coffee, or go to the toilet. (You’d be amazed how many times I’ve found sudden inspiration in the ‘smallest room of the house’.)
9. Ask someone else for advice
Again, if you’re too close to the issue to see the solution, ask another person unrelated to the problem for their input. Many times they will hit on the reason because they don’t share your perspective. If you don’t have another developer in your team, log a question on the Adobe Captivate User Forum. In most cases you’ll get a reply within hours, sometimes within minutes. However, if you DO expect someone else to help you, please note the next suggestion…
10. Give detailed info about the issue
Effective troubleshooting is based on accurate information, otherwise it’s just guesswork. So, if you expect someone else to help you debug an issue for, you need to give them everything you know about the issue and its context. It’s often just some minor detail that reveals the underlying cause or causes. So, if you ever log an issue on the Captivate forum, it will greatly increase your chances of finding a solution if you provide the helpful people there with the kind of basic information outlined here below.
Provide this information:
Your Captivate major and minor version numbers, and whether or not all recent patches or updates have been installed.
Computer operating system. E.g. whether the computer is PC or MAC and the OS version.
Web browser version (if published content is playing in browser).
If content is delivered from an LMS, which one and which version.
If using an LMS, which integration technology standard (AICC, SCORM, or xAPI / Tin Can) and version (e.g. SCORM 1.2).
Sadly, Captivate developers often post questions on the forum without providing any of this information, which then requires the person offering help to go to the extra trouble of asking all the same questions I have listed above. The more information you supply, the more likely someone can help resolve your issue.
11. Read the user help doco!
And last but not least….when all else has failed and you’ve wasted far too much time searching for answers, do what you should have done when you first installed the application: Read the user help file documentation!
Large companies never expect their employees to just ‘pick up’ a new business application by playing around with it. But many newbie Captivate developers somehow expect that they will have no issues by doing exactly that. They don’t invest in any training (beyond watching a few YouTube videos) and they neglect to look up or download the Adobe Captivate HELP documentation. The inevitable result is that they strike issues and then label Captivate as not being ‘user-friendly’.
Captivate does have some areas where its usability could certainly be improved. But it’s never going to be completely idiot-proof.