access violation et grid

Je n'ai pas posté ce sujet dans les bugs car je pense que çà n'en ai pas un.
C'est une astuce pour contourner le problème décrit ci-dessous.

Je suis entrain de mettre au point un programme qui utilise un GRID de 10 colonnes et 111 lignes.
J'ai fait une SUB qui remplit les cellules du grid de la manière suivante:

Code:

SUB remplie_grid()
 lig%=1:' pour commencer l'affichage en ligne 2 du grid
 Clear Dlist1%:file_load Dlist1%,"fichier_X"
  for n%=1 to count(Dlist1%)
     lig%=lig%=+1
     a$=item_read$(Dlist1%,n%):' extrait chaque ligne du fichier
     EXPLODE(a$): ' 17 éléments par ligne (dont 10 qui doivent être affichés)
     grid_write grid%,lig%,2,element$(1)
     grid_write grid%,lig%,3,element$(2)
   ' et ainsi de suite pour les dix colonnes  
' ajoutez ici WAIT 10 et plus de problème
  next n%
END_SUB

Important: Une fois l'affichage fait, le programme attend un clic dans une cellule pour faire autre chose...

J'ai mis longtemps à trouver pourquoi cette SUB me déclenchait un "Access Violation......" de manière aléatoire au passage dans la sub (si, et seulement si, l'utilisateur à fait le click décrit ci-dessus). Ce qui n'empêchait pas le programme de tourner correctement, après avoir validé le message d'erreur.
Je me suis dit que l'affichage dans les cellules était pris de vitesse par l'exécution ???

La solution: j'ai insérer un WAIT 10 (car 5 était insuffisant) juste avant NEXT n%. Et plus de vilain message !

Voilà je voulais partager l'astuce avec vous, pour le cas où....

A+

Et si tu essayais de de remplacer le "WAIT 10" par "DISPLAY" ? Cela devrait permettre à Panoramkic de finir les affichages... Est-ce que ça fait le même effet ?

Bonne idée Klaus, j'ais fait l'essai, mais ce n'est pas parfait.

Cela améliore les choses, mais le message "Access Violation" arrive encore, mais moins souvent.

Comme je l'ais expliqué plus haut, un WAIT 5 ne suffit pas il faut un WAIT 10.
De plus, il me semble que Jack avait précisé que DISPLAY n'était rien d'autre qu'un WAIT 1, mais je n'arrive pas à retrouver le sujet sur le forum.

Je précise que c'est valable pour ma configuration (Processeur I3), pas certain que l'on puisse recréer le problème sur une autre configuration.
Je pense que le problème est lié à la vitesse d'exécution du PC, mais je n'en suis pas certain.
Pour arriver à recréer le "bug" il faut que dans la boucle FOR/NEXT il y ai un traitement assez conséquent (dans mon cas 17 éléments X environ 90 lignes d'un fichier = 1530 traitements à faire).
Donc, selon moi, il faut adapter la valeur de WAIT suivant la configuration du PC et le nombre d'éléments à traiter. Mais je ne suis pas très affirmatif, c'est mon intuition.

J'aimerais savoir ce que Jack en pense.

A+

Essaye Jean-Claude de mettre dans le sous-programme de réception d'un on_click ce que je pais maintenant .
Je mets en début:
repeat: wait 100: until scancode = 0

C'est à dire que la procédure démarre après le relâchement  de la souris. Depuis que je procède ainsi, je n'ai pratiquement plus de problème.

Merci Cosmos, j'ai essayé mais çà ne marche pas non plus.

Dans mon programme, le on_click sur le grid est désactivé par off_click jusqu’à la fin du traitement du click précédent. Ce n'est donc pas un problème de click.

La solution WAIT 10 convient parfaitement (seulement  à l'exécutable, pas avec l'éditeur) et ne ralenti pas trop l'affichage.

Ce que j'ai omis de dire, dans mon premier poste, c'est que entre le on_click sur le grid et la SUB d'affichage, il y un tas de contrôles sur le fichier et un enregistrement de celui-ci. Tout çà est assez lourd (environ une seconde de traitement avant l'affichage lui-même)

Merci quand même, car ton tuyau peut servir pour d'autres cas.

A+