Plantage après un ":" oublié en fin de ligne

Dans un programme que je suis en train d'écrire, j'ai la séquence suivante:

Code:

change_attrib:
  nc% = number_change
  off_change nc%
  i% = nc% - 45  : ' indexe dans attrib%(no%,i%)
  v% = position(nc%)
  attrib%(no%,i%) = v%
  text no_attrib%+i%,attrib%(no%,i%)
  on_error_goto change_attrib_err
  select i%
    case 1: left no%+1000,v%
    case 2: top no%+1000,v%
    case 3: width no%+1000,v%
    case 4: height no%+1000,v%
    case 5: color no%+1000,v%,attrib%(no%,6),attrib%(no%,7)
    case 6: color no%+1000,attrib%(no%,5),v%,attrib%(no%,7)
    case 7: color no%+1000,attrib%(no%,5),attrib%(no%,6),v%
  end_select
change_attrib_err:
  off_error_goto:
  on_change nc%,change_attrib
  return

C'est une routine évènement on_change appelée par un certain nombre de scroll bars.

Or, mon programme "plante", et je dois le tuer par le gestionnaire des tâches. Celui-ci m'indique qu'il y a DEUX programmes du nom de mon application, ce qui en général veut dire que mon programme a ouvert une fenêtre avec un message d'erreur. Mais impossible de voir ce message, l'éditeur est bloqué, et le seul moyen d'en sortir est de tuer la tâche par le gestionnaire des tâches.

Or, je viens de m'apercevoir qu'apès une modif, j'ai laissé traîner un ":" immédiatement après la ligne "off_error_goto" (3ème ligne avant la fin). C'est bien sûr un oubli, une erreur. si j'enlève ce seul caractère, le programme marche parfaitement. Il m'a fallu 1 heure pour comprendre ce qui se passe.

Question:
- quel est le message d'erreur que Panoramic ne m'a pas voulu laisser voir ?
- peut-on éviter un bouclage aberrant dans ce cas (plus de 50 % d'UC) ?

Bonjour Klaus,
Bizarre ce que tu as...
J'ai fais ce test :

Code:

LABEL Test
DIM A
BUTTON 1
ON_CLICK 1,Test
END
Test:
    MESSAGE "test" :
RETURN

et j'obtiens le message : "(52) Not correct string expression: Sequence error, bad character."
Donc le message est en relation avec l'instruction AVANT les 2 points...
dans ton cas (off_error_goto), j'obtiens "illegal instruction"

Je veux bien, mais dans les deux cas, l'instruction est correcte, aussi bien le message que le off_error_goto.

Dans ton exemple, on a bien le mesage. Dont acte. Dans mon cas, le message n'est peut-être pas visible parce que ça se passe dans une routine évènement, mais j'en doute...

Dans tous les cas de figure, le message d'erreur est inapproprié. Il y a un ":" qui introduit une nouvelle ligne. Or, celle-ci est vide, et devrait donc être traitée comme une ligne blanche, ni plus ni moins.

Salut tout le monde.

Comme l’a dit Klaus, le ":" est un séparateur d’instructions. Si, après le ":", il n’y a rien,
moi je comprends qu’il s’agit d’une instruction ‘vide’ et le système doit l’ignorer comme dans cet exemple :

Code:

print "Salut"
:
print "tout le monde"

Mais, lorsque le ":" se trouve sur une ligne qui comporte déjà une (ou plusieurs) instructions, le système affiche un message d’erreur !
Comme dans cet exemple :

Code:

print "Salut" :
print "tout le monde"

Là, ce n’est pas logique ou il y a quelque chose qui m’échappe.

A+

Regardez ces exemples

Code:

print " Salut" :  :
print " tout le monde"

Code:

label suite
print " salut"
goto suite : suite:
: : :
print " tout le monde"

Exécution sans erreur. No comment !

C'est bien ce que je dis: il y a quelque chose d'anormal.

Oui, quand il y a ":" seulement, c’est l’erreur mais quand il y a plusieurs (mêm non séparés par des espaces) c’est correct !

Bonsoir à tous,
Moi je pense que l'erreur provoquée par les 2 points est logique et normale!
pourquoi? Eh bien, panoramic croit avoir affaire à une étiquette et détecte que celle-ci n'a pas étée déclarée en label et il part en erreur.
Souvenez-vous d'un post il n'y a pas si longtemps où l'on parlait des mots clés que l'on pouvait utiliser en variable, eh bien pour les labels ,'est pareil!
Dans ce premier exemple, je déclare le mot clé print en label, et tous ce passe bien avec les 2 points après l'instruction print:

Code:

label print
print:
print "SALUT"

Dans ce second exemple, j'ai omis de déclarer print en label, et je met 2 points après, et là, panoramic détecte l'erreur!

Code:

label gogo
gogo:
print:
print "SALUT"

Et si vous mettez plusieurs fois 2 points l'un à la suite de l'autre, comme il n'y a pas d'instruction, Panoramic ignore et il n'y a pas de bug.
Donc Papydall, désolé, mais je ne crois pas qu'il y a erreur, c'est toi qui provoque l'erreur de PANORAMIC.
A+

bignono a écrit:

Moi je pense que l'erreur provoquée par les 2 points est logique et normale!
pourquoi? Eh bien, panoramic croit avoir affaire à une étiquette et détecte que celle-ci n'a pas étée déclarée en label et il part en erreur.`

Mais dans le code suivant, il n’y a pas lieu de croire à une étiquette puisque le ":" ne suit pas un identificateur !

Code:

print "Salut" :
print "Tout le monde"

Si panoramic croit avoir affaire à une étiquette, le message d’erreur devrait être en rapport.

De 2 choses l’une : ou bien on peut mettre une instruction vide ou on ne peut pas ?
Dans le 1er cas

Code:

Print "bonjour"  :

Il ne doit pas y avoir d’erreur. Comme erreur il y a, j’en conclus que PANORAMIC n’accepte pas une instruction vide.

Dans le second cas

Code:

Print "bonjour"
:
Print "tout le monde"

La 2eme ligne est une instruction vide et elle est acceptée, j’en conclus que PANORAMIC accepte une instruction vide.
Pour moi, c’est un paradoxe !

De tout façon : ce n’est pas grave car on sait maintenant ce qui est correct et ce qui ne l’est pas.

C'est bien sûr exact: on a identifié ce qui marche et ce qui ne marche pas. Mais le problème n'est pas là. Les messages d'erreur sont censés nous mettre sur la voie, et ce n'est pas le cas ici. D'autant plus que dans mon programme, cela "plante" avec une charge de CPU croissante, je vois bien dans le gestionnaire des tâches qu'il y a DEUX fenêtres avec le titre de mon programme, mais la seconde est impossible à afficher à l'écran, même par "basculer vers" du gestionnaire des tâches. Seul moyen d'en sortir: tuer la tâche par le gestionnaire des tâches, et je suis marron: aucun moyen de savoir ce qui c'est passé ni à quelle ligne. Comme je l'ai déjà dit: 1 heure de bidouillage avec des messages et autres, pour trouver l'endroit ! C'est vrai: ce n'est pas grave, mais c'est dommage.

Je suis absolument d'accord avec toi.

Et dans le cas où on considère qu’il ne s’agit pas de bug (ni ce cas, ni l’utilisation des mots réservés comme identificateur, ni la virgule double dans un DIM etc..),
Je réitère ma proposition d’avoir des messages d’erreurs plus explicites pour que le programmeur localise aisément l’endroit où ça cloche.

Bonjour,
Tu as raison Klaus, mais pourquoi tu n'utilises pas la fonction TRACE pour t'aider au debugage ?...

sinon, après plusieurs essais, j'en arrive à la conclusion que les ':' sont neutres, sauf si ils se situent en fin de ligne.
Dans ce cas, il est interprété comme étant une déclaration de label
voir exemple :

Code:

LABEL Test,Titi:DIM A:::::ON_ERROR_GOTO Titi:BUTTON 1:::ON_CLICK 1,Test:END:Titi:
MESSAGE "Erreur":TERMINATE::RETURN:Test:
off_error_goto::MESSAGE "ok ça marche":RETURN

Bon je conseille pas de coder de cette manière hein ?

Salut tout le monde.

Regardez ce code :

Code:

label =,;,!,?,@,

gosub = : gosub ; : gosub ! : gosub ? : gosub @
end

=:
  print " Salut"
return

;:
  print " tout"
return

!:
  print " le"
return

?:
  print " monde"
return

@:
  print " OK"
return

Il y aura certainement quelqu’un qui me dirait que c’est normal et logique.
Moi, je n’ai pas de commentaires ; je constate seulement !

Y a un sérieux problème, là....

C'est vrai que ça fait bizarre. Je pense aussi qu'il y a un problème, mais !
Si après tout ça n'empèche pas de programmer, d'arréter le programme pour une erreur, alors qu'on a bien conscience que c'est bizarre, alors pourquoi pas.
Si ça n'arrète pas les autres instructions, moi je m'en fou!

Tout ça, c'est curieux et intéressant. Mais mon problème n'est pas là.

Il est clair qu'intentionnellement, je n'utiliserai jamais de telles constructions.
Dans mon cas, le ":" en fin de ligne est un résidu d'une opération de suppression.

Que Panoramic n'aime pas cette construction, soit. C'est à moi de me plier aux règles de Panoramic
Mais il faut que je puisse avoir un message indiquant le type d'erreur et l'endroit !
Généralement, c'est le cas, et le problème est identifié rapidement. Mais pas dans ce cas. Pourquoi ?
Car je voyais bien qu'il y avait un message d'erreur:
la barre de tâches montrait une seconde fenêtre avec le titre de mon programme,
et le gestionnaire des tâches montrait un secon process. Mais il n'y avait aucun moyen de vosualiser ce message !
La fenêtre restait cachée EN-DESSOUS de la fenêtre de mon programme.
Même en le réduisant, ça ne marche pas, car la fenêtre du message disparaît aussi.
Il m'a fallu 1 heure et des dizaines d'essais pour trouver.

Et cela m'est déjà arrivé plusieurs fois: le message d'erreur existe bien, mais reste caché, quoi que je fasse.
Et il y a même pire: il y a des messages avec une croix blanche sur fond rouge comme logo,
et ces messages ne comportent PAS de numéro de ligne et ne BLOQUENT PAS Panoramic !
Là aussi, ce n'est pas évident de trouver l'origine.

J'ai 3 suggestions à faire, pour mieux gérer ces aspects:
1. ouvrir les fenêtres de messages dans une fenêtre non-MDI-child
2. forcer un TOP_MOST sur la fenêtre de message
3. afficher tous les messages dans une "console Panoramic", un peu comme Java peut le faire.
Ce serait un process totalement indépendant, normalement avec une fenêtre chachée,
et qui s'afficherait à réception d'un message.

J'ai déjà signalé quelque part le coup des messages d'erreur qui sont planqués invisibles derrière la fenêtre d'exécution, on est bloqué et on ne sait pas pourquoi, et il faut tuer la tâche panoramic pour continuer...

La console avec les messages d'erreurs, les warning (et si j'osais, je dirais bien aussi, l'état de varuiable que l'on souhaite suivre, ce serait un rêve merveilleux ... )