Bogue PRINT@

par André C.

Etat de la question

Le manuel de l’Atmos présente l’ajout du paramètre “@X,Y;” à la syntaxe de la commande PRINT comme une simple option supplémentaire par rapport au PRINT de l’Oric-1, permettant d’afficher aux coordonnées X,Y de l’écran. PRINT@X,Y;plist n’est pas présenté comme une nouvelle commande, mais comme une simple extension de syntaxe.

D’autre part, rappelons que si on place un “;” à la fin d’une commande PRINT, les coordonnées X,Y de la “case” qui suit le dernier caractère affiché sont mémorisées pour l’impression suivante. Il est alors possible d’utiliser ces coordonnées pour une autre commande d’affichage. Pour le dire plus simplement, après le “;” final, le curseur reste à clignoter au bout du dernier affichage et représente le prochain point d’affichage.

Ce que ne dit pas le manuel

Dans certains cas, il peut y avoir un conflit entre les paramètres “@X,Y;” et le “;”final. En effet, au niveau du code, lorsqu’un paramètre “@X,Y;” a déjà été détecté au début de l’analyse de syntaxe, un paramètre “;” en fin de ligne n’est ni rejeté, ni traité correctement.

En pratique

Lorsqu’on utilise une série de PRINT@X,Y;”CHAINE”, pour chacune des commande PRINT@, la chaine mentionnée est bien affichée aux coordonnées X,Y indiquées, pas de problème. Si la longueur de la chaîne est supérieure à la place disponible, l’affichage se poursuit tout naturellement à la ligne suivante.

Si pour une raison quelconque on est amené à mélanger des commandes PRINT@ avec d’autres commandes d’affichage,  on risque de rencontrer des problèmes. Voyons ce qu’il en est avec un exemple.

Soit le petit programme ci-dessus.

La chaîne figurant à la ligne Basic 10 comporte 30 caractères. Le premier caractère, un “2”, sera affiché dans la “case” de coordonnées X=2, Y=10. Le dernier caractère, un “1”, sera affiché dans la “case” X=31, Y=10. A cause du “;” final, le curseur restera à clignoter sur la case suivante. (Le déroulé du programme est trop rapide pour voir ce curseur clignotant, sauf si on place une commande GET R$ en fin de ligne).

La ligne Basic 15 affiche “OK” au curseur, c’est à dire au point X=32, Y=10. Ici encore, le curseur restera en attente sur la case suivante  à cause du “;” final.

La ligne Basic 20 devrait commencer l’affichage de la chaîne “SALUT LES GARS!” (15 caractères) de la “case” de coordonnées X=16, Y=10 et la terminer à la “case”  X=30, Y=10. Au lieu de ça, seul “SALUT ” est affiché correctement, le reste de la chaîne, soit “LES GARS!”, est rejeté au début de la même ligne n°10 de l’écran et, curieusement, pas à la ligne suivante.

Vous me direz que le “;” n’a logiquement rien à faire à la fin du PRINT”OK” et que cela relève d’une faute de conception du programme Basic. Peut-être. Mais la commande PRINT proprement dite est mal codée : Lors de l’analyse de syntaxe, la rencontre d’un paramètre “@X,Y;” devrait entraîner la neutralisation des coordonnées X,Y en cours et leur remplacement par celles indiquées par “@X,Y;”.

Si on retire le “;” après le PRINT”OK” l’affichage rentre dans l’ordre et redevient ce qu’il doit être.

Ceci montre bien qu’il ne faut pas utiliser de “;” à la fin d’une commande PRINT@, sauf raison particulière et en toute connaissance des risques.

Il n’est pas toujours simple de comprendre ce qui se passe. Ainsi, si on garde le “;” après le PRINT”OK”, mais que l’on supprime le “;” de la ligne Basic 10, alors la chaîne “SALUT LES GARS!” s’affiche correctement. Le truc, c’est qu’entre temps les paramètres X,Y ont été régénérés lors du retour à la ligne pour afficher “OK”. Même si le curseur reste à clignoter après le “K” de OK, le PRINT@ qui suit opère sans problème.

Autre petite curiosité, lorsqu’on déplace progressivement l’affichage de la chaîne “SALUT LES GARS!” vers la droite en augmentant la valeur de X à la ligne Basic 20, on observe une rupture pour X=34. Pour X=33, le reliquat “LES GARS!” est rejeté au début de la même ligne de l’écran, alors que pour X=34, il est affiché au début de la ligne suivante, comme il se doit !

Il n’existe pas de commande LPRINT@, donc pas de problème de ce côté-là.

Oups !

J’ai fait en dernier ce que j’aurais dû faire en premier : Vérifier si la bogue “PRINT@;” était déjà connue. Et oui : Vous pouvez consulter le CEO-mag n°10, page 9 de mars 1991, qui en donne une autre démonstration (article de Roger B.).

Conclusion

Comme vous l’avez vu, la situation peut devenir complexe quand la syntaxe d’une commande est mal gérée. Il est difficile de prévoir à l’avance le résultat final. Ceci vaut évidemment pour toutes les commandes Basic de l’Oric réputées pour leurs bogues. A la liste IF THEN ELSE, RND(), POS(), CLOAD, POINT(x,y), ‘ (apostrophe pour REM), EDIT, DRAW, il faut donc ajouter PRINT@;

Salut et Oricité !