To me, one of the best-kept secrets in Authorware is the "off" automatic option on conditional interaction responses. When I first saw this, I asked myself "Why would someone want to set up a response, then turn it off?" Finding no good answer, I promptly chucked this option into the "Authorware features that Amy does not use" pile.

During the Beta for Authorware 6, we started talking about the defaults for responses and decision branching, and Grace Daminato and Joe Ganci were kind enough to explain to me what the "off" option does. It turns out that the response is not actually off. What is actually off is the "automaticness" of the response. In other words, user interaction is required for the response to even consider matching.

Imagine an interaction with a conditional set to continue branching that is to the left of a button response. When the user clicks on the button, the conditional will check to see if the condition in its title is met. If it is, it will execute whatever is inside the conditional before continuing on to execute the code inside the button response.

If the conditional is to the right of the button response, the button must be set to continue for the conditional to match. This is because the default "try again" matching will loop directly back to the interaction without matching anything to the right of the button. "Exit interaction" branching will totally leave the interaction, and no further responses can be matched.

What is this good for? Well, suppose you want to provide immediate feedback for all responses. You could use a single conditional set to TRUE with some judging logic and the feedback display, rather than including this logic in all responses. That way, if you wanted to change something in the feedback, you only have to do it in one place.

You probably already know that, to change a text entry field's properties, you can run the piece until the text entry field is visible on the screen, pause the piece, and double-click the field. You may have noticed that many of the text entry field's properties are not accessible through the response properties.

This is because the text entry field itself actually belongs to the Interaction, not the response. This is why you can only have one text entry field per interaction.

The good news is, in Authorware 6 you can customize your interaction icon to give you the same text entry field every time without having to copy and paste an existing interaction. Just set the text entry field options to look the way you want, then drag the interaction back to the Icon Palette. After that, all your interactions will have the text entry field you set up.

Models for the next release of Authorware

The chat will be Tuesday, May 14. The chat will start at 6:30 pm CDT. For the rest of the world, that is 6 hours earlier than current UK time and 5 hours earlier than GMT. In the US this is 7:30 pm Eastern, 5:30 mountain, and 4:40 pacific. Expect the chat to last around 1.5 hours.

One guest is already confirmed. That is Dan Wilson, who thought of the idea. I am considering asking Dan Clinger, so we can be totally confused as to which Dan we are talking to. I might try for Danny Engleman again for good measure.

Last week, you met my lap cat, Jake. This week I'd like to introduce Tux, my younger cat.

I had to think long and hard before settling on the name "Tux." I am sure no one can guess why. Tux is every bit at cute as he is in this picture, and has the most lovely green eyes. I don't have a picture that does them justice.

The Aware Listserv is a great resource for me. In addition to the great discussion on the list, people often post links to their own or other sites. Here are some I especially like.

Ever wonder what the functions in WinApi do? The mystery is at least partially solved in the Authorware WinAPI guide.

Greg Miller's Absolutely Authorware site is visually lovely, and has loads of great examples, most of them advanced.