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.
Here is some background, we have over 200 modules each in an individual .exe. Once a module is completed the learner click on a button to go to the next module (exe). We use a jumpfile function at the end of each module to transfer the variables and open the next exe for training. Here is a printscreen as well however it doesn't have a lot of information. The runtime error happens as soon as they click on the button to jump to the next module.
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.
Thank you Steve, these are definetly a couple of things that can possibly assist in finding the problem. We have already checked the variables and according to the developers these are 100% correct.
What I do want to know more about is the obscure little bug you mentioned. Where can I find additional information regarding this. We already have authorware 7 but due to the size of all the content we haven't upgraded from 6.5.
In terms of navigation, at the beginning of each file it queries the db to detemine if the file must be done by the specific learner. This is done using a simple binary structure where 1 means the module must be done and 0 that it must be skipped. The modules are set under different courses and at the beginning of each course the same check is performed to determine if there are active modules to be completed in the course. If not it goes to the next course or module and performs the same check. We do not use a "home" file but do use a file to obtain initial configuration information from the database and jump to a specific module in the system if the learner is already busy with a session. If the learner starts for the first time it just jumps to the first course in the structure.
Unfortunatly we cannot quit the individual exe's as this will mean we will have adapt the entire workflow of the system.
If you can perhaps assist me with information on the bug as you mentioned, I might be able to work from there.
Thank you so far for the assistance.
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.
Can you perhaps explain what the initial type of the variables are? How you set it, what types there are etc? Also I do not understand what you mean with the linear list vs property list? Sorry, I am actually the DBA on the system and trying to resolve the issue and my Authorware knowledge is not that good.
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 :-/
Thanks Steve, well it might have come out wrong but I do use Authorware, I am just not that proficient with it as a dedicated developer would be.
Mike regarding the bug, can you shed some light on that? Can it be possible that it could cause the issues we are experiencing? I do believe our variables are set correct (slight assumption from my part) as the entire systems does work running it locally on my test environment.
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.
Thank you Mike. We are now in the process of checking all the variables in each exe. This will take some time and I will post back as soon as we are done testing etc. One question though, is there a limitation on the amount of variables transfered from one file to the next?
Thanks for the help guys.
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.
Hi Mike, we redid all the variables in the application, however we are still experiencing the same issue with the authorware runtime. Any other tips, tricks or suggestions regarding this? We have determined that it does not happen randomly, but with specific exe's within the solution and the structure in the specific exe's are the same as in the other 270 odd exe's which the application consist of.
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.