Tweet
INFO: Tips for Debugging Action Lists in AutoPlay Media Studio 4.0
Document ID: IR04011The information in this article applies to:
- AutoPlay Media Studio 4.0
SUMMARY
This article provides tips on how to debug your action lists.
DISCUSSION
AutoPlay Media Studio 4.0 has over 150 different actions available. Combine this with the numerous available events and the result can be a very complex project. As complexity and the number of actions increases it gets harder and harder to debug your actions if a problem occurs. This document provides you with tips on how to zero-in and debug problems in your action lists.
The Help File
Make sure to look through the help file when you run into a problem. The help file is an incredibly in depth reference for AutoPlay users. Try searching the help file and looking in the Index. If your problem is specific to a group of actions, be sure to visit the help topic (in the Command Reference) for every action in this group.
If you cannot find any information in the Command Reference, try browsing the User's Guide, which is also located in the help file. Chances are your problem will be categorized by one of the eleven chapters found in the User's Guide.
Be sure to look at the Action examples that can be found in the help file (Command Reference | Actions | Examples). Often simply seeing examples of how an action works will help you find any logical problems that your action list may contain.
Message Boxes
One of the most useful debugging tools available to you are message boxes. Message boxes are a great way to see what the value of a variable is at any time throughout the program, and a good way to determine how far the execution of your action script gets. To display a message box use the Dialog.MessageBox action.
For example, if you have three while loops in an action list and when you run your program it gets caught in an endless loop, a good starting point for your debugging would be to put message boxes around each while loop. Use the form: "Entering While Loop one", "Exiting While Loop one", "Entering While Loop two", and so on. Once you have determined which while loop is causing the problem, put some message boxes inside the while loop to determine what your variables are equal too.
Message boxes are also useful if you are having problems with conditions. If it appears that an IF block is not being executed when you think it should be, try replicating the IF condition in a message box. So if your if condition is: "%MyVar% < %ProgCounter%" use a message box to display "%MyVar% < %ProgCounter" on the screen. This will probably explain why the IF condition is failing.
The bottom line is whenever you run into a problem use message boxes to zero in on the area where the problem is occurring, and then use message boxes to determine what your variable are equal to at that moment. This method will solve 90% of all problems you encounter with your action lists.
Note: When you are done debugging your action lists be sure to remove all of the message boxes that you used for debugging purposes.
Tip: For very large projects it may not be feasible to continually add and remove debug message boxes each time you encounter a problem. In situations like this creating a "Debug" build configuration and a "Commercial" build configuration might be the best idea.
In the "Debug" build configuration set the #DEBUG# design-time constant to TRUE, and in the "Commercial" build configuration set #DEBUG# to FALSE.
Now "wrap" all of your debug message boxes in the following way:
IF (#DEBUG#)
Dialog.MessageBox("MyVar = %MyVar%")
END IFSo instead of having to add and remove your debug messages every time you encounter and solve a problem, you would simply have to switch build configurations.
Log Files
Sometimes it is not feasible to use message boxes to debug an action list. For example if you have a while loop that loops 500 times, you do not want to have hit the "O.k." button 500 times so see what the problem may be.
In cases like this creating a log file is the best way to debug your action list. To set up a log file first create a text a file somewhere on your hard drive, something like "C:\MyProj_LogFile.txt" or simply "C:\LogFile.txt" is a good idea. This file will be your log file. Then use TextFile.Write actions to write the same information that you would have put in a Message Box, to your log file. Make sure the If file already exists drop down is set to "Append data to end of file."
Tip: Since you are probably going to use the same log file more then once, it is a good idea to separate each run using a header. Use a TextFile.Write action on the "Project Startup" event to create your header. Here is an example of a header that you might consider using:
************************************************** *****************************
%Date%
%Time%
************************************************** *****************************Note: Use the System.GetDateTime action to set %Date% and %Time% before you create the header.
Now each time you debug your action list, a header containing the full date and time when the test was performed will be inserted into your logfile.
Error Messages
Most actions in AutoPlay have settings that control how the action reacts when an error occurs. These settings can be found on the On Error tab of the Actions Properties dialog.
As soon as you run into a problem make sure that all of the actions in the problem area have their User Notification set to Verbose. Also make sure that none of the actions have their User Notification set to None. After doing this re-run your AutoPlay application and write down any error messages that you encounter. Once you have recorded all of the error messages try looking at the help topic for each action in the help file for information on that error message.
Note: Knowing the exact text of your error message is also useful when contacting support or posting a question in the forums.
If you receive error messages that reference an Object on your page (i.e. "The AVI Object 'AVIObject1' could not be found") make sure that the object's name and the name in your action are spelt identically. You should also make sure that the object has not been deleted, and that the object is visible when the action is called.
If you are still having problems with an error message try using the Custom User Notification level. Be sure to always include the %LastErrorMsg% variable at the top of your custom message so that you can see the value of the verbose error message when the error occurs. If the action references any variables add them to the custom error message to determine what their values are at the time of the error.
Variable Names
Be extremely careful when typing in a variable's name, misspelling a variable name can result in problems that are very difficult to diagnose. Remember referencing the variable %SrcDri% is not the same as referencing %SrcDir%.
Tip: If it appears as thought your variable is not being expanded check the spelling, as this is likely the cause.
Tip: When entering a variable name use the Insert Variable option instead of typing the variable in. Right-Click on the field and select the Insert Variable menu item. This will display a list of all the "Built-In Variables", "Built-In Constants", and "User-defined Variables". This is a good method to ensure that no spelling mistakes make their way into your variable names.
File Paths
If you are receiving an error message that is telling you that AutoPlay cannot find a specified file, be sure to write down exactly what the error message says and the path to the file that it provides. Once you have done that open up My Computer and browse to the file. Compare the path to the file from the error message and the path you have browsed to. Note the differences in the two paths and then change your action in AutoPlay so that it points to the file properly.
Note: When referencing a file using an action it is almost always necessary to use a variable in the path. Usually %SrcDir% or %SrcDrv%, should be used. Make sure that the path to your file makes sense when these variables are expanded.
Check all the Events
If you are having a problem with a certain action list, check all the other events available to the Object, Page, or Project. Make sure there are no "conflicting" actions on an event that occurs just before, or right after, the problem action list.
Cascading Events
When objects are overlapped in AutoPlay certain events will "fall through" both actions. This means that if you have a Text Object over an Image Object the "Mouse Click" event will occur for the Text Object and then for the Image Object. When this occurs it is said that the "event cascades", or that the event is a "cascading event". When events cascade unbeknownst to the developer, actions can sometimes conflict with each other (i.e. change variable values, hide object, etc.) and cause problems.
If the event that the action list that is causing problems appears to be on a cascading event, be sure to check all relevant events for "conflicting" actions.
Getting Help
Sometimes, when debugging, you will go through all of the above steps and still not know what the problem is, in cases like this it is often necessary to get help from someone. The best place to do this is in AutoPlay's online forums at the Indigo Rose website (http://www.indigorose.com).
The online forums are a fantastic repository for AutoPlay Media Studio 4.0 information, try searching the forums a few times before you post your problem. Chances are that if you have run into a problem, someone else already has and the solution has been posted to the forums.
If you cannot find any similar posts on the forums, then post your problem or question. When posting be sure to post all the information that you have, you can never post too much information. Here are some tips as to what sort of information you should post:
- The symptoms of your problem.
- What actions are being used, a pseudo code example is always helpful.
- All of the steps that you have taken in your attempt to debug the problem.
- Any of the applicable error messages that you have written down during the debugging process.
- The steps (if any) that other users can take to replicate the problem
Posting all of your information in a clear manner will make it easier for the other users, and members of the Indigo Rose staff, to understand your problem and hopefully provide you with a solution.
If you think it might be easier to show people your problem then to explain it with words you can post the page where you are having problem by attaching the *.pg4 file to your post, or copy the actions in AutoPlay and paste their XML code into your post. To paste your actions XML code simply select the specific actions in AutoPlay and press CTRL-C, then go to the forums where you are posting your message and press CTRL-V to paste the action's XML code into your post.
KEYWORDS: AutoPlay Menu Studio 4.0, Action lists, Debugging, Errors
Last reviewed: October 22, 2002
Copyright © 2002 Indigo Rose Corporation. All rights reserved.