PC SOFT

FOROS PROFESIONALES
WINDEVWEBDEV y WINDEV Mobile

Inicio → WINDEV (versiones precedentes) → Traitement boucle lecture fichier externe
Traitement boucle lecture fichier externe
Iniciado por Alain, 06,mar. 2019 19:26 - 17 respuestas
Publicado el 06,marzo 2019 - 19:26
Bonjour à tous

Dans le traitement d'une boucle de lecture d'un fichier externe je lis dans la doc WD que l'on peut faire:

// Sortie selon une condition SI
BOUCLE
// Lecture d'une ligne du fichier texte
UneLigne = fLitLigne(NumFic)
SI UneLigne = EOT ALORS SORTIR
TraiteLigne(UneLigne)
FIN


ou

// Sortie selon une condition TANTQUE
BOUCLE
// Lecture d'une ligne du fichier texte
UneLigne = fLitLigne(NumFic)
TraiteLigne(UneLigne)
A FAIRE TANTQUE UneLigne <> EOT


Je me demande qu'elle est la réelle différence, notamment pour éviter un éventuel bug de lecture, puisque finalement le résultat est le même...

Merci de vos avis.
Alain
Miembro registrado
299 mensajes
Popularité : +16 (16 votes)
Publicado el 06,marzo 2019 - 23:29
La seconde méthode est plus propre techniquement
Il n'y a pas de rupture de boucle
Miembro registrado
141 mensajes
Popularité : +5 (5 votes)
Publicado el 19,marzo 2019 - 08:27
Bonjour,

La deuxième version est peut-être plus propre, mais elle n'est pas strictement identique à la première.

Dans la deuxième, si le fichier est vide, il y a appel de "TraiteLigne(UneLigne)" et pas dans la première.

Personnellement, j'utilise la boucle :

/// Lecture de la première ligne du fichier texte
UneLigne = fLitLigne(NumFic)
TANTQUE UneLigne <> EOT
TraiteLigne(UneLigne)
......
// Lectures suivantes
UneLigne = fLitLigne(NumFic)
FIN

BonDev

--
Yann Wagner

WHY-GemA sàrl
Publicado el 20,marzo 2019 - 09:12
Yann a écrit :
Bonjour,

La deuxième version est peut-être plus propre, mais elle n'est pas strictement identique à la première.

Dans la deuxième, si le fichier est vide, il y a appel de "TraiteLigne(UneLigne)" et pas dans la première.


Bonjour,

Oui c'est vrai, c'est comme cela que je procède, et de toute façon il faut tester en préalable si le fichier s'est bien ouvert avec un "FOuvre" donc il n'y a pas de risque de lecture de ligne vide, normalement.

Il est vari également que le fichier peut très bien exister mais être vide, dans ce cas, circulez il n'y rien à lire...
La constante EOT est le caractère présent à la fin des fichiers externes mais je ne connais pas vraiment son comportement.
Voilà pourquoi je préfère une double sécurité par:
TANTQUE laligne <> "" ET laligne <> EOT




//On tente d'ouvrir le fichier
IdFichierClient = fOuvre(LeDisqueEnCours+"\monrepertoire\mondossier\client.cli")

//Si on a pu ouvrir le fichier c'est qu'il existe, on peux le parcourir
SI IdFichierClient <> -1 ALORS
TANTQUE laligne <> "" ET laligne <> EOT
TableAjouteLigne(TableClient,ExtraitChaîne(laligne,1,TAB),ExtraitChaîne(laligne,2,TAB),ExtraitChaîne(laligne,3,TAB)
laligne = fLitLigne(IdFichierClient)
FIN
SINON
RETOUR
FIN
fFerme(IdFichierClient)
Miembro registrado
141 mensajes
Popularité : +5 (5 votes)
Publicado el 20,marzo 2019 - 20:03
Bonjour,

Tu fais une grave confusion entre une ligne vide et EOT.... Ce n'est pas parce que la ligne est vide que tu es à la fin du fichier.
Dans ton code, il manque la première lecture. C'est une ERREUR...

Après tout dépend de la fiabilité de ton fichier en entrée... Mais dans tous les cas, ton code devrait être :

//On tente d'ouvrir le fichier
IdFichierClient = fOuvre(LeDisqueEnCours+"\monrepertoire\mondossier\client.cli")

// Lecture initiale
laligne = fLitLigne(IdFichierClient)

//Si on a pu ouvrir le fichier c'est qu'il existe, on peux le parcourir
SI IdFichierClient <> -1 ALORS
TANTQUE laligne <> EOT
SI laligne <> "" ALORS
TableAjouteLigne(TableClient,ExtraitChaîne(laligne,1,TAB),ExtraitChaîne(laligne,2,TAB),ExtraitChaîne(laligne,3,TAB)
FIN
laligne = fLitLigne(IdFichierClient)
FIN
SINON
// L'ouverture n'a pas abouti
RENVOYER Faux
FIN
fFerme(IdFichierClient)

// La lecture a abouti
RENVOYER Vrai


--
Yann Wagner

WHY-GemA sàrl
Publicado el 21,marzo 2019 - 11:25
Bonjour Yann,

Merci mais ce n'est ni une confusion ni une erreur, c'est juste que lors du copier/coller depuis le code source ne n'ai pas "copier" toutes les lignes.

D'autre part, il me semble que:
TANTQUE laligne <> EOT
SI laligne <> "" ALORS
..
fait le même boulot que:
TANTQUE laligne <> "" ET laligne <> EOT

mais avec ma façon de faire, les deux conditions sont réunies dans une seule instruction, c'est plus propre non ?

De plus et selon moi, les deux conditions cumulées dépendantes l'une de l'autre par le "ET" apparaissent comme plus sûres car cumulées justement.

En effet asservir simplement la deuxième condition à la première "SI laligne <> "" ALORS" mais uniquement durant le "TANTQUE laligne <> EOT' apparait moins sûr car dans ce cas les deux conditions ne dépendent pas l'une de l'autre mais la deuxième à la première uniquement, mais bon je peux me tromper.


Alain
Miembro registrado
2.566 mensajes
Popularité : +222 (260 votes)
Publicado el 21,marzo 2019 - 12:36
@Alain: Ca ne donne absolument pas le même résultat.

Exemple concret:
toto

tutu


Dans le premier cas, on traitera les lignes avec toto et tutu.

Dans ton cas il ne traitera que la ligne toto puisque la 2ème ligne est vide. De plus, je pense que tu vas rentrer dans une boucle infinie car tu ne relis jamais la ligne suivante. Donc laligne aura toujours la même valeur.

--
Cordialement,

Philippe SAINT-BERTIN
Mensaje modificado, 21,marzo 2019 - 12:38
Miembro registrado
141 mensajes
Popularité : +5 (5 votes)
Publicado el 21,marzo 2019 - 13:20
Re,

D'accord avec Philippe

Yann

--
Yann Wagner

WHY-GemA sàrl
Publicado el 21,marzo 2019 - 19:31
Comme lors de l’écriture du fichier aucune ligne vide n'est possible, en lecture le laligne <> "" du test
TANTQUE laligne <> "" ET laligne <> EOT
est surement superflu mais en l'état cela fonctionne parfaitement.

Pour reprendre l'exemple de Philippe, entre son "TOTO" et son "TUTU" il y à bien une ligne vide mais à cet endroit précis le fichier n'est pas finit, donc les deux conditions de test ne sont pas "à vrai", donc on sort de la boucle avec le sinon RETOUR.
De même supposons que après son "TUTU" il y ai une ligne vide, là aussi les deux conditions ne sont pas "à vrai" et donc on sort.

Je me goure ?

Je pense que je vais retirer le laligne <> "" qui finalement n'apporte rien de plus.
Bon dev

Alain
Miembro registrado
2.566 mensajes
Popularité : +222 (260 votes)
Publicado el 22,marzo 2019 - 08:08
Bonjour,

Tu te trompes.

Lorsque tu parcours le fichier, si la ligne est vide, la première condition est vraie mais la seconde est fausse, tu ne rentres donc pas dans le TANTQUE et tu continues à boucler avec la même valeur. Ta variable laligne reste vide et ne sera jamais égale à EOT. Tu as donc bien une boucle sans fin.

C'est valable si la ligne est au milieu du fichier, mais c'est aussi valable si elle au début ou à la fin du fichier. Et une ligne vide en fin de fichier c'est courant voir même extrêmement courant... En général les fichiers csv terminent tous pas une ligne vide.

--
Cordialement,

Philippe SAINT-BERTIN
Publicado el 22,marzo 2019 - 10:38
Donc selon toi la boucle ci-dessous ne peut fonctionner.

TANTQUE laligne <> "" ET laligne <> EOT

traitement de la ligne

SINON
RETOUR
FIN


Pour moi tant que les deux conditions sont "à vrai" on traite la ligne lue et si l'une des deux conditions est "à faux" alors on sort de la boucle.
En langage humain cela donne:
Tant que la ligne contient quelque chose ET qu'on est pas en fin de fichier, on traite Sinon on sort.

Je ne vois pas ou est le soucis, puisque cette boucle fonctionne parfaitement.
Quant tu auras un moment, teste la et tu verras.

Bon dev
Alain
Miembro registrado
141 mensajes
Popularité : +5 (5 votes)
Publicado el 22,marzo 2019 - 12:09
//Pour moi tant que les deux conditions sont "à vrai" on traite la ligne lue et si l'une des deux conditions est "à faux" alors on sort de la boucle.
//En langage humain cela donne:
//Tant que la ligne contient quelque chose ET qu'on est pas en fin de fichier, on traite Sinon on sort.

DONC, si la ligne est vide, tu sors.. ET TU NE TRAITES PAS LA FIN DU FICHIER. cqfd..

Bon dev.

Yann

--
Yann Wagner

WHY-GemA sàrl
Miembro registrado
2.566 mensajes
Popularité : +222 (260 votes)
Publicado el 22,marzo 2019 - 12:16
Oui c'est vrai cette boucle fonctionne parfaitement tant que la première ligne n'est pas vide et qu'il n'y apas de lignes vide au milieu de ton fichier

--
Cordialement,

Philippe SAINT-BERTIN
Publicado el 22,marzo 2019 - 18:36
Yann a écrit :
#DONC, si la ligne est vide, tu sors.. ET TU NE TRAITES PAS LA FIN DU FICHIER. cqfd..

Oui c'est bien ça, comme préciser précédemment le fichier créé ne peut comporter de ligne vide donc pas de soucis à la lecture, le laligne <> ""est juste là au cas ou, mais il n'est indispensable c'est vrai.

#Philippe SB a écrit :
#Oui c'est vrai cette boucle fonctionne parfaitement tant que la première ligne n'est pas vide et qu'il n'y a pas de lignes vide au milieu de ton fichier.

Oui, également vrai, avec le même commentaire que la réponse faite à Yann.

Merci et bon dev
Alain
Miembro registrado
2.566 mensajes
Popularité : +222 (260 votes)
Publicado el 24,marzo 2019 - 12:17
Tu excuseras ma réflexion, mais il me semble qu'il y a un petit manque d'expérience au milieu de tout ça. Tu pars sur le principe qu'il ne peut pas y avoir de ligne vide sans même le savoir.

Malgré le fait que ce soit toi qui génère ce fichier, tu n'es pas à l'abri d'une erreur et de te retrouver avec un RC 1 ligne sur 2, ou au début. Il peut se passer un certain temps, voir un temps certain avant la détection de cette erreur et ce jour là, il va te falloir rechercher l'origine du problème, le corriger et corriger tous les fichiers qui ont mal été traités. Tu vas donc perdre un temps considérable pour ne pas avoir ajouté une ligne de code qui t'aurais pris 2 secondes. Que de temps perdu.

D'autre part, dans le développement on ne travaille pas qu'avec des fichiers que l'on conçoit soi même, c'est même plus souvent le contraire quand tu travailles avec des prestataires externes et là non plus tu n'es pas à l'abri d'une erreur ou d'une modification. J'en ai encore fait les frais il y a quelques mois...

On te donne donc des pistes et des conseils pour traiter les cas qui peuvent se produire. A toi de les suivre ou non. Il n'y a que l'expérience personnelle qui peut te faire avancer et comprendre qu'il est préférable de penser à des cas particuliers plutôt que de les ignorer.

--
Cordialement,

Philippe SAINT-BERTIN
Publicado el 25,marzo 2019 - 10:20
Excuses non acceptées, car des excuses restent toujours à présenter et ne peuvent êtres imposées. ;)
Ce n'est pas un principe, c'est un fait, dans le fichier créé, il ne peut y avoir de ligne vide.
Mon idée de fond était de dire si jamais pour une raison ou une autre cela plante à cause d'une ligne vide que doit faire le soft ? se planter ou juste afficher un message indiquant que le fichier n'a pas pu être lu correctement.

T'es gentil Philippe de me le rappeler, mais je sais qu'on peut travailler avec/sur des fichiers créés par d'autres, mais en l'espèce ce n'est pas le cas.

Lorsque j'écris le fichier, ce dernier ne contient absolument aucune ligne vide et comme il ne contient pas de "texte pur" , pas de soucis liés à de la tabulation ou autres RC.

C'est le contenu de tous les champs et variables du soft, qui sont pris l'un après l'autre pour être écris dans le fichier avec leur repère/indice d'identification et ce sans strictement aucune ligne vide.
Donc à la lecture, la boucle générale va traiter la lecture relative à chaque repère/indice dédiée et cela tant que 'laligne <> EOT'.

Ma question initiale était juste, dois-je par sécurité, rajouter un 'tant que 'laligne <> " ' à cette boucle générale ?
afin de donner une autre éventuelle sortie de la boucle SANS BUG.

Bon dev
ALain
Miembro registrado
141 mensajes
Popularité : +5 (5 votes)
Publicado el 25,marzo 2019 - 13:03
En plus, il est susceptible...

Avec Philippe, on essaie juste d'aider et de faire avancer les connaissances.

Mais quand on a affaire avec un gros réfractaire, moi j'abandonne. Ce n'est pas parce qu'un code fonctionne qu'il est correcte.

Si Alain est SUR qu'aucune ligne vide ne peut être contenue dans son fichier, alors il est stupide de faire une "double sécurité" qui n'a que le mérite de prendre du temps et d'alourdir le code.

A bon entendeur, salut.

Yann

--
Yann Wagner

WHY-GemA sàrl
Publicado el 25,marzo 2019 - 15:00
Bonjour YANN,

Pourquoi dire de moi "En plus, IL est susceptible", comme si je n'était pas là pour le lire, c'est stupide comme réaction.

Merci de bien relire mon post initial.
Je n'y demandait pas, de passer pour quelqu'un qui ne sait pas gérer une simple boucle avec deux conditions de sorties mais juste un avis relatif les deux exemples de la documentation WD, c'est clair non ?

Mais bon, le présent forum n'est pas le lieu ou entrer dans une discussion stérile.
Merci de vos avis tout de même.

Bon dev

Alain,
Dont la susceptibilité n'a d'égal que son talent et sa gentillesse, contrairement à d'autres apparemment...