Bonjour,
Je dois imbriquer le parcours de deux fichiers, disons fic1 et fic2. Pour chaque enreg de fic1, je parcours ceux de fic2, que je dois hModifier, de même que ceux de fic1.

J'ai écrit un code du style :

POUR TOUT fic1
//code de traitement
POUR TOUT fic2
//code de traitement
hModifie(fic2)
FIN
hModifie(fic1)
FIN

Surprise, tout marche bien... jusqu'à l'enreg. n° 4260 de fic1 : là, WinDev plante avec "erreur inattendue" (même hSurErreur n'arrête pas l'erreur en question !)

Si fic1 comporte moins de 4260 enreg, tout va bien, au-delà ca plante invariablement au moment de lire l'enreg 4260, j'ai eu le pb avec plusieurs fichiers de tests différents (un de 3500 enreg : tout va bien, un de 6500 enreg : planté à 4260, un de 30000 enreg : planté à 4260)
Le fic 2 ne semble pas avoir d'incidence (10 ou 1000 ou 20000 enreg, aucune différence)

Mais si j'écris un code du style :

POUR TOUT fic1
//code de traitement
HLitPremier(fic2,clé)
TANTQUE pas hEnDehors
//code de traitement
hModifie(fic2)
hLitSuivant(fic2,clé)
FIN
hModifie(fic1)
FIN

ben là tout marche, tout le temps, quel que soit la taille du fichier fic1...

Alors, bug ou limite quelconque non documentée du "POUR TOUT" ???
Parce qu'implémenter des nouveautés c'est bien, mais comme je pars toujours du principe qu'en cas de problème dans mes projets, c'est MA programmation qui est fautive et pas WinDev (et c'est effectivement quasi systématique...), ben là j'ai passé plusieurs heures à débogguer mon projet pour constater que pour une fois ce n'est pas moi qui me plantais, puisqu'avec le parcours traditionnel au lieu du POUR TOUT mon programme fonctionne exactement comme je l'avais prévu !!!

Bonjour

Il faut toujours faire attention à nos manipulations de l'AGL, si on tombe sur un blocage quelconque il faut être sûre que tout le code est bien vérifié et tout est bon. Sinon, on signale ce blocage à l'éditeur de l'AGL.

En tout cas, peux tu nous passer ton code ? est quelle est la version interne de ton AGL.

Ha ben j'ai trouvé ce qu'il se passe...

En fait "POUR TOUT" fonctionne (je l'aurais juré...) mais avec une (importante!) particularité dont je ne trouve aucune trace dans la doc...

Cet ordre "POUR TOUT" utilisé sans paramètre permet uniquement de "lister" les enregistrements d'un fichier, pour en faire une table ou un pour créer un autre fichier filtré, ou pour servir de référence pour un autre fichier etc... mais PAS pour parcourir un fichier et MODIFIER les données de ses enregistrements, particulièrement les clés ! L'instruction "POUR TOUT" CHANGE de clé de parcours en cours de boucle pour une raison que j'ignore, et modifier dans la boucle avec hModifie les données des enregistrements du fichier parcouru par "POUR TOUT" perturbe (jusqu'à planter WinDev) la suite du parcours à cause à ce changement de clé de parcours !
La preuve : si je laisse le code "POUR TOUT fic1", ça plante à un moment donné, mais si j'ajoute simplement le paramètre "SUR clé" (l'ordre devient "POUR TOUT fic1 SUR clé"), tout se déroule merveilleusement bien...

En d'autres termes, si vous utilisez POUR TOUT, IMPOSEZ-LUI une CLE de parcours, NE le laissez PAS trouver seul "la meilleure clé de parcours" !!!