5 Replies Latest reply: Jan 4, 2013 5:43 AM by Lilybiri RSS

    Is there a limit on the number of Variables and Conditional Advanced Actions?

    RodWard CommunityMVP
    RodWard Jan 4, 2013 12:04 AM

      Hi all,

       

      Does anyone have any data on whether there is some kind of design limitation on the number of User Variables or Conditional Actions that can be built into a single Captivate module?

       

      I'm currently working at a client site using Captivate 5.5 on Windows XP. The course I'm building is a very complex software simulation that requires LOTs of dynamic behaviour driven by User Variables and Conditional Advanced Actions.

       

      I seem to recall hearing somewhere on this forum that users were finding if they exceeded 200 variables, then Captivate would start crashing.

       

      I've now reached 196 User Variables and 90 Conditional Advanced Actions on one particularly complex module.  Everything was proceeding fairly well until this afternoon, where Captivate 5.5 has crashed 3 times on me while editing some complex Conditional Advanced Actions.

       

      So have I 'hit the wall', or is there something I can do to work around the limitations? (I've already cleared the cache but it still crashed once after that.)

      • 687 Views
      • Tags:
        • 1. Re: Is there a limit on the number of Variables and Conditional Advanced Actions?
          Jim Leichliter Community Member
          Jim Leichliter Jan 4, 2013 5:15 AM (in response to RodWard)

          Hi Rod,

           

          First I want to say "Thank You" for the awesome support you give to the Captivate community and this forum.

           

          I don't have any data, but I do have a suggestion:  Use JavaScript to offload some of the variables and advanced actions.  Why would JavaScript help?

          1. It would reduce the number of advanced actions and Captivate variables you might need in your .cptx project.
          2. Memory Management during runtime.

           

          When viewing a course in a browser, you have two virtual machines (VMs) at your disposal.  The Flash VM and the browser's JavaScript VM.  Leveraging the two in combination can give you a bit of "load balancing" when it comes to memory management and garbage collection.  If you can accomplish the majority of the logic in JavaScript, I'd go that route because I believe JavaScript is more forgiving when it comes to garbage collection than the Flash VM.  Every Cp variable you create and advanced action that uses those variables will consume memory from your computer during design time and runtime... so needless to say that it's critical to leverage the two VMs when you're pushing the limits of the software.  Ever wonder why when you create a Cp variable, Captivate asks you to enter the number of characters you need to display the variable?... to help control the amount of memory needed for the project.  When you're pushing the limits, also take a look at your Cp variables to ensure they're not utilizing more memory then they really need.

           

          However, there are some Cp actions you can't do with JavaScript like show/hide other Cp elements, or enabling or disabling Cp objects.  So part of the challenge is to figure out what would work best using JavaScript vs. Advanced Actions & Cp variables in Captivate.

           

          I personally avoid Advanced Actions if possible.  However if you're creating a project for a client, they may not have the necessary JavaScript expertise to maintain the project once you hand it over.

           

          Best,

           

          Jim Leichliter

          • 2. Re: Is there a limit on the number of Variables and Conditional Advanced Actions?
            RodWard CommunityMVP
            RodWard Jan 4, 2013 5:22 AM (in response to Jim Leichliter)

            Thanks Jim.  I do REALLY need to get my head into JavaScript more nowadays, especially with HTML5 becoming such a hot topic.

             

            However, the issue with this project is much as you suggest.  Once I move on, the people that will need to maintain the content and functionality will NOT be able to do anything with JavaScript if I went that route.

             

            The thing about this module in question is that it runs perfectly fine in the browser.  It's just crashed Captivate 5.5 a few times this afternoon while I'm editing.  So I suspect that the runtime isn't actually the issue I've got (yet).  It seems to be more that the editing environment reaches some kind of critical mass and once you push it past a certain point it starts to get wobbly on its feet.

             

            I've been keeping a list of enhancement requests for Variables and Advanced Actions that I'm intending to share with Adobe.  I think I have nearly 50 so far...

            • 3. Re: Is there a limit on the number of Variables and Conditional Advanced Actions?
              Jim Leichliter Community Member
              Jim Leichliter Jan 4, 2013 5:38 AM (in response to RodWard)

              Can you see evidence of possibly a memory leak issue?  What happens when you fire up task manager and watch the CPU memory as you try to edit the project?  I had a similar issue when using the drop down and combo box stock Cp widgets.  Once I removed then from the project, all was fine.

              • 4. Re: Is there a limit on the number of Variables and Conditional Advanced Actions?
                RodWard CommunityMVP
                RodWard Jan 4, 2013 5:41 AM (in response to Jim Leichliter)

                That's a good idea.  I've knocked off work for the day now.  I'll look into it more on Monday.

                • 5. Re: Is there a limit on the number of Variables and Conditional Advanced Actions?
                  Lilybiri CommunityMVP
                  Lilybiri Jan 4, 2013 5:43 AM (in response to RodWard)

                  Only 50 Rod? For myself I do not count them any more, but feel reluctant to share more lists with Adobe, since nothing ever makes it in new releases. Promises, promises and then.... over

                   

                  Is there  no way to 'reuse' variables? I find that it could solve some of the problems... Pity that it is 5.5, 6 allows a lot more saving on advanced actions with the shapes.

                   

                  Lieve