Think of something that you wish Authorware could do but it doesn't?  Let the our good friends at Macromedia know via the wishlist.

Please let us know if you find any of the materials on this site inappropriate or offensive. Please include the url and why the material should be reviewed.

Comments and questions about the site are also welcome. Please no Authorware questions, use the AWARE list.

Let's say you have a totally linear course (blah). The only thing the student can do is move back and forward. They can't even Exit or go to a menu unless they are on the first or last screen. As I said, blah. Bad blah. In a case like this, however, you can use Prevent Auto Erase easily enough because the only place you have to remember to use the erase icon on the prevented erase icon is on the screen before and after the icon is used. Oh, and of course if you have one of these icons on the first or last screen, then you have to remember to do it in the menu and/or exit screen. With a really badly designed linear course, you already start to see a problem.

What about when you have cooler stuff included, like the ability to jump to a different screen from a topics menu, or a history button, or a search button? Now you have a problem because your course is no longer all that linear, and you have to account for the prevented auto erase icon on *EVERY* screen of your course. With a little guruness, you can set up an Erase to erase all the icons that have prevent auto erase set in one place that is called everytime you change screens, but that's not a very good solution.

Oh, sure, you're saying, but I'll keep careful track of what's going on and make sure that any place that can be jumped to will have an Erase icon set to erase the prevent auto erase icon. Granted (maybe) but what about future programmers who work on your file? If this is quick and dirty thing you're doing that has no need of maintenance, no big deal. But if maintenance is an issue, watch out!

So what about the automatic erasing? How does it work? Let's say you have an Interaction icon inside a Framework page. If you set a response of the Interaction to Don't Erase, that response will not erase as long as you're in the interaction. If your Interaction icon is set to not erase, the response will not erase until the framework page is changed. If your Interaction icon is set to erase, then your responses (still set to not erase) will also erase as soon as the interaction is exited.

So think of it as parents and children. If the children get dismissed, the parents may stick around. If the parents get dismissed, the children have to leave as well.

If you must keep something on the screen from one screen to the next, it's better to have that something be in a library and have a link on both screens, neither one set to prevent auto erase. If the user jumps out at any point, the icons will erase properly. Of course, if you want something not to erase through all your pages (such as a background image), just put it in the framework entry pane.

Also, don't forget the DisplayIcon function. If you place a Display icon at the top of your file in a place it won't execute automatically (such as if it's attached to a Decision icon set to Calculated Path 0), then you can call it up as many times as you wish using the DisplayIcon function.