Attention, vous ne savez pas à l'avance quand l'utilisateur cliquera sur un bouton permanent, c'est-à-dire quel est l'état de l'écran avant qu'il sélectionne un bouton permanent. En réalité, il n'est pas nécessaire de le savoir tant que les instructions exécutées suite à la sélection du bouton permanent n'ont pas d'effet sur ce qui était préalablement affiché. Par contre, si le feed-back du bouton perpétuel modifie l'état préalable de l'écran, par exemple s'il en efface une composante, Authorware ne reconstituera pas celui-ci à son retour. Donc, si vous désirez qu'à son retour, l'utilisateur trouve l'écran dans son état au moment du départ, il faut concevoir les feed-back des boutons permanents comme des composantes hermétiques:
Cette recette n'est bien entendu pas toujours applicable, par exemple, si vous ajoutez un bouton 'effacer écran'! Elle correspond néanmoins à une règle d'hygiène assez générale en programmation qui consiste à réaliser des bouts de programme (procédures, routines, fonctions, modules, ...) les plus autonomes possibles les uns par rapport aux autres. En effet, si le feed-back d'un bouton permanent n'a aucune interférence avec l'état préalable de l'écran (par exemple, un élément de l'écran préalable rend illisible le texte du feed-back), il suffit de tester ce feed-back une fois pour toutes. Par contre, s'il y a interférence, vous devrez tester le feed-back pour chaque endroit depuis lequel il peut être appelé.
Outre les interférences graphiques, vous risquez de rencontrer des interférences sur des variables lorsque: le programme du bouton permanent change la valeur d'une variable utilisée dans le programme, ou vice-versa. Cette interférence peut être voulue: par exemple, le bouton perpétuel 'plus vite' modifie la variable 'vitesse' utilisée par les animations du programme ou le bouton 'calculs moins difficiles' modifie les variables qui déterminent la génération des calculs. Par contre, si cette interférence n'est pas explicitement voulue, une règle générale consiste à utiliser des noms différents pour des variables utilisées à différents endroit du programme. D'autres langages de programmation disposent des variables 'locales', de telle sorte que, même si elles portent le même nom, leur valeur dans une procédure n'affecte pas leur valeur dans une autre procédure. Authorware utilise des variables locales pour certaines icônes, par exemple la variable tries@"question1" indique le nombre d'essais effectués à l'interaction "question1" et n'affecte par exemple pas la valeur de tries@"question2". Il en est de même des variables utilisées par Authorware dans les icônes de décision, d'animation, etc. Par contre, les variables que vous créez sont des variables globales. Chaque variable a une valeur unique, quel que soit le point du programme où elle est appelée.