Skip navigation
CAP Deloitte
Currently Being Moderated

Random Runtime Errors

Aug 24, 2011 12:34 AM

I was wondering if there is a way to track and debug runtime erros in authorware?
We are running authorware 6.5 published exe's on windows xp/windows7 environments.  The system randomly crashes when trying to jump from 1 exe to the next.

  • Currently Being Moderated
    Aug 24, 2011 12:56 AM   in reply to CAP Deloitte

    Depends. Some runtime errors used to be common and easy to address - e.g. by

    searching MSDN. Care to share symptoms and/or screenshot?

    Mark as:
  • Currently Being Moderated
    Aug 24, 2011 2:59 AM   in reply to CAP Deloitte

    Lots of things to think about here.


    First thing - have you looked carefully at the data that is passed and

    what the receiving file expects to see? I think it is possible to

    introduce a conflict with malformed data. Easiest way to confirm this

    is to Trace your data on screen, or to a text file, before you do the

    JumpFile. Make sure that the receiving files all have the required

    variables in place. Make sure that if you are passing List data you

    are careful to check that you pass what you think you are passing.


    Of course, if the issue is as random as you say, this may not help, soooo ...


    I remember random issues like this many years ago with a similar

    setup. Apparently there was a very obscure bug that caused it and, I

    think, was fixed in Authorware 7.


    You are not going to like my suggestion, but here goes ...


    Download the Authorware 7 trial and repackage all your lessons and

    test them again. I know horrible suggestion, right? With 200 lessons

    that could take a while to test


    Alternatively you can try looking at how you navigate between lessons

    - is it a constant forwards and random trail? Or do your learners

    always return to a 'home' file, or menu, at stages throughout the



    Lastly, you can also consider simply force-closing the course at

    times. Without knowing exactly how your lessons are stitched together,

    I don't know hw practical it is for you to try this, but I think you

    can use Quit(n) to quit and restart an Authorware file ... I forget

    what number you need to use, 1, 2, 3 or 4.



    Mark as:
  • Currently Being Moderated
    Aug 24, 2011 5:33 AM   in reply to CAP Deloitte

    One thing that might not be obvious to check is the 'initial type' of the variables. There's an internal similarity between number variables and list variables. If the type of the passing module differs from the type of the receiving module, then Authorware could reference memory that doesn't belong to it. There's also a possibility of that when the type of list being linear list vs. property list differs from module to module.




    Mark as:
  • Currently Being Moderated
    Aug 24, 2011 6:07 AM   in reply to CAP Deloitte

    Mike Baker should know more about the bug than me, since he was one of

    the Authorware ngineers. My memory says it was something internal to

    Authorware and not something you can specifically address.


    As for Type - each variable can be examined in the Properties window

    of the Autorware file. The variable type can be set there


    "" denotes alphanumeric

    0 denotes numeric

    [] denotes List

    Re: Random Runtime Errors denotes Property List


    These can also be set in code, but I beleive Mike is referring to the

    initial setting of the file before any code is launched. Basically if

    you are passing a List called "Data" there should also be a variable

    in the receiving file called "Data" and it should be set as a list in

    the Properties window.


    None of this will make any sense if you don't use Authorware  :-/





    Mark as:
  • Currently Being Moderated
    Aug 24, 2011 8:10 AM   in reply to CAP Deloitte

    As Steve mentioned, the initial type is set up when you create the variable. The setting can be viewed in the variables dialog and adjusted there as well. Just change the content in the entry box from 0 or "" to an empty linear list [] or an empty properyt list [:]. Some of Authorware's variables are populated with the actual values and some are tracked by memory address. For instance in the linear list the value contains a memory address. So lets say you have var foo := 123 in one file and var foo := [] in antoher file. When the transfer happens from one file to another it's possible for Authorware to be given the number variable but the type isn't changed to number, it still thinks it's a list. In most cases the conversion of type is handled for you but there are a couple of combinations where it slipped through without the data type update. Because of this it's important to have variables that stay consistent types between if they're copied between files.



    Mark as:
  • Currently Being Moderated
    Aug 25, 2011 5:22 AM   in reply to CAP Deloitte

    There shouldn't be a limit to the amount that can be transferred. The variables and their contents are transferred using a file. They're written out to the file, then the new content is loaded into the runtime, then the variable's content is read in from the file.



    Mark as:
  • Currently Being Moderated
    Oct 12, 2011 5:56 AM   in reply to CAP Deloitte

    Do you know how to get to the reports from the crash? Next time it happens get copies of those files and we can take a look at them to see if it's within a particular module such as one of the XMO or U32 files. That might narrow down the possibilities.

    Another thing we can try is to strip out extra unused data. When you work on an Authorware file it saves time by not compressing everything over and over and over each time you modify the file. So there's a menu option "File / Save and Compact" that removes this excess. If the file is small enough, and your machine has enough ram to hold it, you can select the whole file, copy it onto the clipboard, and paste it into another file. Save and compact is good, copy and paste does a similar operation in a different way and sometimes gets more. The trouble with copy and paste is that it can lose references between icons if the icon is renamed because of a conflict.

    If you try to copy and paste and you get an error during the paste, then you may have found a corrupt icon. What we usually do in this case is binary chop search. Copy half the file and try to paste, if no error then copy the other half. Keep dividing the working section in half until you isolate the icon causing the problem. Yank that icon and rebuild it.

    Just an afterthought... are you using a database to store information? I know that ODBC crashes if you try to close a resource twice. I didn't think of it at first because it was random crash.



    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points