Access violation

J'ai une requête pour Jack, mon problème est l'Access violation en sortie de programme que je retrouve de temps en temps.
Il s'agit vraisemblablement d'une erreur de ma part (erreur de structure ?) mais que je ne m'explique pas.
Par exemple dans le cas suivant:

Code:

ON_CLICK n, Fin
...
Etiq:
    ...instructions... dans l'objet n
    WAIT 50
GOTO Etiq
END
Fin:
TERMINATE

Et je récupère un "Access violation at address 48" en sortie (clic sur n), qu'il faut acquitter.

Puisque le programme est terminé, serait-il possible d'inhiber cette erreur, et que Panoramic libère systématiquement toutes les ressources pendantes avant de quitter, sans signaler d'erreur ? (c'est d'ailleurs ce qu'il doit faire, après avoir signalé l'erreur).

Je sais, ça veut sans doute dire que quelque chose ne va pas dans la structure...

PS le problème a déjà été évoqué dans 2 ou 3 autres posts, sans réponse convaincante. J'ai essayé en mettant le END après le TERMINATE, mais ça ne change rien.

PS2: serait-il possible d'avoir une précision meilleure que la seconde (avec TIME$) dans le mesure des temps ? Par exemple l'équivalent de TIMER du basic.
Il y a bien WAIT, mais le gros inconvénient c'est qu'on ne scrute pas les événements pendant le wait...


Pour en revenir au problème de l'access violation, je pense que le problème vient du faut qu'on ne passe jamais dans le END, puisqu'on reste à tourner dans la boucle.
Qu'à cela ne tienne, je mets le END juste avant le TERMINATE:
Fin:
END
TERMINATE
et là, erreur sur le END: "(29) Not Correct Arithmetic Expression" !

JL35 dans le PS c'est sûr que ça fait la même chose le END est après le TERMINATE le programme est déjà quitter.

Je sais, mais ça avait été suggéré par Jack dans un exemple ici:
https://panoramic.1fr1.net/a-l-aide-f6/access-violation-apres-execute-t343.htm?highlight=access+violation

Je n'ai plus ce problème de violation. Je pense, mais ne suis pas certain, que la sructure du programme est importante. Je m'expllique:

1) terminate doit être le dernier mot du programme
2) il faut impérativement un END après les dim et les label, même s'il n'y a pas d'ojets
3) ce END doit être placé avant le premier label
4) Ce qui oblige d'utiliser un GOSUB prog si il n'y a pas de On_Click pour faire partir le programme

Code:

dim a$
label fin, prog

' les objets etc...

gosub prog:rem ' ou un déclencheur dévènements (on_click)
END
' --------------------
prog:
' déroulement du programme
return
' -------------------
fin:
terminate

A+

ATTENTION: ceci n'est pas écrit dans le manuel utilisateur de PANORAMIC. Cela n'engage que moi.

Effectivement, il y a quelquefois encore des erreurs "acces violation..."
ça ne m'arrive pas souvent car, comme je l'ai déjà expliqué,
je n'aime pas les boucles surtout du genre infinies ou pouvant l'être.
Mais il y a des fois où on n'a guère le choix...
Et il me semble que ces access violation machin ne surviennent que lorsqu'il y a des boucles (pas forcément infinies), dont on cherche à sortir d'une façon ma foi très normale.
Comme dans cet exemple :

Code:

dim i
label fin , boucle
button 1
on_click 1,fin
alpha 2 : top 2,50
gosub boucle
end
boucle:
for i=1 to 500
 wait 1
 caption 2,i
next i
return
fin:
terminate

Si on clique sur le bouton assez vite (avant affichage de 500)
alors on a un acces violation de machin truc chouette
par contre, si on attend que la boucle ait terminé ses petits tours
(que le chiffre 500 se soit affiché dans l'alpha)
alors il n'y pas de acces violation truc bidule.
Au fond, ne pourrait-on pas dire qu'il s'agit d'un bug,
car enfin, sortir d'une boucle est une idée plutôt normale !

Hé oui il y a un os,

Code:

dim i, fin$
label fin ,fin2 , boucle
button 1
on_click 1,fin
alpha 2 : top 2,50

gosub boucle
end

boucle:
for i=1 to 500
if fin$="OK" then exit_for:goto fin2
 wait 2
 caption 2,i
next i
return

fin:
fin$="OK"
goto boucle
fin2:
terminate

J'ai mis le WAIT à 2, car pour moi c'était trop rapide

EXIT_FOR n'a pas eu l'effet que j'attendais ! (???)

A+

Salut jjn4.
C'est une particularité que l'on connait, c'est d'ailleurs une des raisons que je m'étaiss les boutons à inactive.
Mais la façon plus correct dans une boucle for next serait d'utiliser une commande:
if clicked(1)=1 then exit_for, et ne pas mettre on_click 1,fin, ce qui génère d'autre problème si cette instruction est nécessaire.
Par contre, je suis surpris par ALPHA, normalement il est dit:

Citation :

UTILISATION
° Un ALPHA est utilisé pour visualiser (avec la commande CAPTION) un texte statique que l'utilisateur ne peut pas changer

J'ai des programme où je ne pouvais pas renommer un ALPHA, et donc j'étais partis sur le principe de mettre une variable sur l'existence ou/non de la présence de ALPHA, ainsi:

Code:

dim teste%
label ecrit

alpha 1:teste%=1

end
ecrit:
if teste%=1 then delete 1:teste%=0
alpha 1:caption 1,"on change le texte":teste%=1
return

Mais si on peut changer le texte d'un ALPHA, mon système de codage devient inutile.
Comme quoi, tout est toujours tout à vérifier
@+

J'ai répondu avant de te lire Cosmos70, Nous avons eu la même idée avec EXIT_FOR (traitée differament).

Pour CAPTION, je ne me souvient pas qu'il n'est jamais fonctionné avec une variable (même pour un ALPHA).

A+

Jean Claude, juste une petite ramarque rapide pour ton exemple de code:
dans la ligne:
if fin$="OK" then exit_for:goto fin2
normalement le goto fin2 ne sera jamais exécuté puisque exit_for fait sortir tout de suite de la boucle (donc vers le return).

Tu dis que le Terminate doit être la dernière instruction du programme, pas forcément, on peut mettre derrière tous les sous-programmes, c'est d'ailleurs ce que je fais toujours.
J'ai aussi essayé avec le END avant le premier label, ça ne change rien.

Sinon, ma boucle à moi qui provoque l'access violation n'est pas une For...Next, mais un branchement direct sur une étiquette, en boucle.

Finalement, c'est peut-être l'emplacement du END qui me pose un problème. Je comprends bien que c'est la mise en attente des événements, mais par exemple je veux:
- définir les objets
- faire une action répétitive dans une boucle (soit For/Next, soit branchement direct) en attendant une action de l'utilisateur, où dois-je mettre le End ? avant ou après la boucle ? si je le mets après on ne passe pas dedans, si je le mets avant on n'exécute pas la boucle.

Finalement c'est toujours le même problème que j'avais eu dans mon petit jeu débile (voir Inutilitaires) où on balade une Form jusqu'à ce que l'utilisateur clique dessus, et là on sort pareil en Access violation.
Comme dit jjn4, c'est une boucle qui ne se termine que sur action de l'utilisateur, il n'y a rien là d'illégitime, mais là encore, où placer le End par rapport à la boucle ?

Je reprends vite fait, vu l'heure.
Pour moi un programme lorsque l'on fait appel à un sous programme, il doit se terminer , c'est à dire aller jusqu'au RETURN avant d'envisager de partir à une autre sub rutine. Si il y a déclenchement par appel d'un bouton, ici, le programme se débranche alors qu'il devrait finir sa tâche avant de partir. C'est d'ailleurs comme que fonctionne Windows, si vous cliquez sur une fenêtre, il faut parfois longtemps avant que cette fenêtre soit accessible. Là vous cliquez sur un bouton qui inter faire, et va directement à terminate. Mais que devient le RETURN qui reste dans la pile. Ce qu'il faudrait peut-être (sur ORIC il y avait POP je crois qui faisait cela) ce serait de pouvoir dépiler lorsqu'on saute un return. Encore faudrait-il savoir si le return a été dépilé ou non?
Donc le saut d'humeur de TERMINATE est normal, puisque la structure du programme n'est pas respecté.
Je ne vois qu'une seul possibilité pour être en accord avec ce basic dans ce cas.
Le bouton de sortie, ne doit pas être évènementiel, c'est dire on ne met pas ON_CLICK. Par contre on teste le bouton.

Code:

dim i ,sort%
label fin , boucle
button 1
rem on_click 1,fin
alpha 2 : top 2,50
gosub boucle
if sort%=1 then goto fin
sort%=0
end
boucle:
for i=1 to 500
 wait 1
 if clicked(1)=1 then sort%=1:exit_for
 caption 2,i
next i
return
fin:
terminate

@+

Jean Claude
pour ce qui est de caption, ce que tu dis est vrai, mais normalement le caption de ALPHA ne devrait pas être modifiable
il y a caption aussi pour button check form sub_menu option qui eux sont modifiable

aujourd'hui jeudi 17 décembre, publié en même temps sur "l'installation d'un électricien déjanté"
Je viens de vérifier ce que j'affirmais hier: on ne pouvais pas changer les alpha comme dit la notice, et c'est vraiment faux.
J'ai repris l'exemple de la fonte donné avec panoramic, et la première fois que j'avais fait ce teste, je n'y étais pas arrivé. Est-ce qu'il y avait un ancien éditeur que ne l'acceptait pas?
Si cela pouvait être vrai, aujourd'hui ce n'est pas le cas, et c'est pas plus mal, parce que je comprenais pas la raison de cette limitation.
@+

Eh bien cosmos, chapeau ! tu m'as résolu mon problème.
Même si je n'ai pas trop compris ce qui se passait avant, si je supprime le
On_Click 1, Fin
du début par
If Clicked1) = 1 Then Goto Fin
placé dans ma boucle sans fin (même pas la peine d'appeler un sous-programme juste pour positionner une variable), je sors normalement par le Terminate, sans l'Access violation.
En tout cas, merci grand chef.

Ton exemple se résume à ça:

Code:

dim i
label fin
button 1
alpha 2 : top 2,50
for i = 1 to 500
    wait 1
    if clicked(1) = 1 then goto fin
    caption 2, i
next i
end
fin:
terminate

Finalement, je crois bien que c'est le traitement de On_Click qui pose un problème d'Access violation.

Merci à tout les 2,

Cosmos70, j'ai compris cette histoire d'évènement, ta solution est effectivement correct, ce qui est astucieux c'est la varaible sort% qui controle la sortie. BRAVO

JL35, es-tu vraiment sur que EXIT_FOR déclenche un RETURN. Je crois que tout les 2, on est trop habitué à QB, qui traite le programme de manière séquentiel et non pas évènementiel.

A+

Non, Exit_For ne déclenche pas un Return, mais un branchement direct après le Next, ce qui dans le cas de ton exemple est le Return.
Tout ce qui est derrière le Exit_For ne sera pas exécuté, aussi bien sur la même ligne que sur les lignes suivantes, jusqu'au Next inclus.

Si tu reprends ton exemple (l'as-tu essayé ?), tu verras que sur le clic tu ne vas pas aller sur fin2 mais sur le return, qui te ramène après l'appel de la boucle, sur le end.

Et là une erreur que j'ai déjà eue, quand tu arrives intempestivement sur le end:
Not Correct Arithmetic Expression
(qui ne correspond à rien).

Heureux que cela vous conviennent.
Je vais bien dormir cette nuit.
@+

Merci JL35, cette fois-ci, j'ai compris. j'aurai dû placer mon goto après le next.
Je vais me coucher un peu moins bete ce soir.
A+

Je vais reprendre ce problème, et dire ce que je crois donner les règles qui conviennent pour Panoramic (cela pourra être remis en question plus tard, vu que Jack travaille là-dessus.
Quelles sont les règles à suivent?
Pour tout appel à une sous-routine, on utilise un bouton, ou autre qui se branche par ON_CLICK ou ON_CHANGE...
Cela permet de faire tel choix, ou tel autre.
Dans les sous-routines, on interdit à ces boutons d'interférer par par exemple: INACTIVE.
Si il est nécessaire d'intervenir sur tel ou tel commande, (dans votre exemple par un bouton de sortie - pour ma part, je n'ai pas été à TERMINATE directement, parce que je pense que dans la majorité des cas, lorsqu'on veut sortir d'une boucle, c'est pour faire autre chose, d'où le choix d'une variable, sinon à quoi sert le programme?) on prévoit les testes de cliquage sur un objet qui parrait éventuellemnt nécessaire. Il est évident, que les objets qui peuvent être appelés, doivent être actives. Il faut aussi avant le return rendre tout actif.
Je pense que si on suit cette façon de procédé, on évite par mal de problème, et semble correspondre à la structure d'un programme.
Que c'est dur de taper un texte avec la moitié des touches effacées.

Faudrait peut-être penser à te racheter un clavier ? ça doit se trouver d'occase pour des clopinettes.

Que de messages !
J'ai plein de choses à répondre alors je vais le faire un par un,
pour ne pas faire de textes longs (moins marrants à lire).

@ Cosmos70
Les alpha ne peuvent pas être modifiés directement par l'utilisateur,
c'est (je pense) ce que l'explication voulait dire.
Mais le programmateur peut les modifier autant qu'il veut sans avoir besoin de les détruire d'abord pour y arriver.
Et de ce fait, l'utilisateur peut aussi modifier un alpha si le programmateur lui en a donné la possibilité :
Exemple très simplifié :
alpha 1
edit 2 : top 2,50
........
if text$(2)<>"" then caption 1,text$(2)
à l'execution, si on tape qqch dans l'edit, cela va apparaître dans l'alpha
et ceci autant de fois qu'on veut.

@ JL35
Je ne pense pas que l'access violation vienne de la position du end
mais du cycle dans lequel le microprocesseur est enfermé
comme dit Cosmos70, l'appel du click interfère avec le cycle
et oblige le microprocesseur à en sortir
et ça ne lui plaît pas
mais je pense qu'il s'agit bien d'un bug
les cycles ne sont pas fait pour rester infinis
il est normal qu'on en sorte !

@ JL35 et @ Cosmos70
Par contre, je trouve la solution proposée pas si terrible que ça.
Car, d'accord, elle ne fait pas access violation, c'est vrai
mais elle ne marche que si on clique avant que ça arrive à 500.
Après, plus rien.
Ou alors, il faut encore programmer autre chose.
Avec les inactive et tout ça, c'est un peu tordu, quand même.
Je préfèrerais un truc sans bug qui marche de façon simple et clean.
Voilà.

C'est vrai que ce n'est pas la position du end, mais apparemment le traitement de On_Click et On_Key qui pose un problème, peut-être un bug.
En tout cas la solution de cosmos me convient en attendant une autre gestion d'événements (sortie dune boucle qui tourne en permanence en attente d'une action utilisateur, et non pas une boucle For/Next limitée).

Mais en attendant, bonne nuit à tous !

Je reviens sur la boucle de 500: rien n'empêche de mettre un
On_Click(1), fin
après le next et avant le end, et ça marche très bien et pendant et après la boucle !
Et c'est assez satisfaisant au point de vue logique.

Je suis désolé, je ne fais que répondre au problème de violation, sans plus, et je parle d'un problème général. Je suppose que le code donné comme exemple pour faire apparaitre la bug de Panoramic, est une partie du codage, et je ne rentre pas dans la suite.
Pour info, aujourd'hui, on peut très bien s'en sortir, on évite on_click pour tester un objet, mais on peut très bien le rétablir pour une autre partie du programme, et de nouveau l'annuler avec je crois click_off (je n'ai pas la bonne version en cours pour vérifier) lorsque cela est nécessaire.
Moi je donne la raison du pourquoi à mon sens. En tenant compte des principes que j'ai décris, ces violations je ne l'ai connais plus.
@+

On s'est croisés et on arrive je crois à la même conclusion.

Bonne nuit JL35

jjn4 et Jean-Claude ont raison concernant le caption d'un ALPHA. Lorsque j'ai pris connaissance de cela à l'époque (qui n'est pas loin dans l'échelle du temps, puisque c'était au mois d'août, mais le temps passe et tout parait lointain ) j'étais au début de la programmation sur Panoramic, et je n'avais pas réussi ce test, et je suis resté sur ce fait. Mais en 4 mois, j'ai repris 4 ans de programmation (qui dit mieux), et j'ai refais les essais, et comme je l'ai toujours dit je ne suis qu'un c... (à ce propos cela ne venait pas de moi, mais j'ai du l'accepter). ça marche la modification d'un ALPHA. Ouf! je l'ai dit.
Par contre je ne suis tout à fait d'accord avec toi pour dire qu'il s'agit d'un bug. Pour moi il y a erreur de codage. Encore heureux que l'on soit en basic, il y a plus de 20 ans, sur les machines 8bits, je programmais aussi en assembleur, et ce genre d'erreur c'était un blocage. Si on se dit programmeur, on doit être méticuleux dans la conception de son code, et là peut-être que Jack pourrait dire ce qu'il en pense: Plus on mets de contrôle pour annuler les erreurs de programmation, et plus on ralentit l'exécution d'un programme. J'ai désassemblé entièrement à l'époque le basic de l'oric et celui du Laser 2000(un émule apple 2e), et les appels interminable de sous-prog en sous-prog pour tout contrôler, pour exécuter un code, mêmes si aujourd'hui on a de la mémoire et de rapidité du processeur, il est préférable à mon sens de ne pas trop en demandé. Certes le programme est plus ou moins recompilé, mais essayé de coder avec d'autre langage évolué, plus ils ont de contrainte, moins ils sont rapide. C'est une analyse mentale vu que je ne peux pas le contrôler, mais je pense que je suis proche de la vérité.
En un mot: faisons attention aux codes de nos programmes.
Merci de m'avoir lu.