Fonction File_Read

A propos du sujet à côté (indexation d'un fichier), j'expérimente et j'observe un phénomène qui me semble curieux:

Code:

dim f$, a$, i%
f$ = "c:\textes\lorem.txt": '  fichier texte quelconque
file_open_read 1, f$
for i% = 1 to 10
    file_read 1, a$
    print str$(i%)+" "+a$
next i%
file_close 1
end

seule la première ligne du fichier est affichée, puis plus rien (seulement les valeurs successives de i%), quelque chose m'échappe ? on dirait que le pointeur reste bloqué sur le retour chariot/interligne.

Utilise file_readln à la ligne 5.

ça mon ami ambroise je le sais bien, c'est ce que je fais habituellement.
Mais là je voulais expérimenter le file_read.

Citation :

Cette commande FILE_READ N,V lit le fichier texte numéro N de la position courante jusqu'au séparateur suivant et stocke le résultat dans la variable V.

dixit le manuel.
Mais qu'est-ce que le séparateur ? un séparateur fixé par l'utilisateur, mais comment ? plus vraisemblablement le changement de ligne ? dans ce cas ça ne marche pas.

J'ai l'impression que file_read ne lit que la ligne pointée.

bon, on s'est croisés.
Mais s'il ne lit que la ligne pointée je n'en vois pas trop l'intérêt, comment déplace-t'on le pointeur ?

Apparemment le file_read est le pendant de file_write, qui écrit une chaîne sans y ajouter de saut de ligne...
mais j'ai du mal à en voir l'utilisation.
En fait je cherche le moyen de se positionner dans un fichier texte sans passer par la lecture séquentielle (pour un fichier à accès direct), mais ça ne doit pas être possible.

J'ai l'impression que file_read ne lit que la ligne pointée. Quand tu ouvres le fichier, le pointeur est à la position 0. La ligne est lue jusqu'au premier séparateur (retour chariot), donc seule la première ligne est mémorisée. Voilà ce que je comprends de l'aide Panoramic. Maintenant, la question est bien celle que tu poses : comment placer le pointeur !

Effectivement, si on ne peut lire que l'article zéro, l'intérêt est très limité !

Pourtant, dans ma boucle ci-dessus, il a bien déplacé le pointeur puisqu'il ne lit qu'une fois l'article 0, mais il patine sur place pour la suite.

Bon, c'est l'heure !

Salut à tous.

J’ai expérimenté et il me semble que la commande ‘FILE_READ N, V’ lis seulement la 1ere ligne, ne déplace pas le pointeur, et je ne trouve pas le moyen de le faire.

D’ailleurs, dès ma découverte de PANORAMIC, j’ai remarqué que la gestion des fichiers, en général, laisse à désirer. Mais, il se peut que je ne connaisse pas suffisamment PANORAMIC.

Alors, j’utilise ‘FILE_READLN N, V’ en association avec ‘FILE_EOF ().

Code:

dim f$, a$, i%
f$ = "c:\machin.txt": '  fichier texte quelconque
file_open_read 1, f$
while file_eof (1) = 0 and i% < 11  :' pour afficher les 10 premières lignes comme dans l'exemple de JL35
    file_readln 1, a$
    print str$(i%)+" "+a$
    i% = i% + 1
end_while
file_close 1
end

Comme a dit JL35, l’intérêt de ‘FILE_READ’ semble être très limité.

C'est vrai que le fichier séquentiel... C'est pas le top.

Si au moins on pouvait utiliser un fichier Random (enfin on appelait cela comme cela...) on aurait un accès direct à défaut d'être indexé.

Encore qu'avec le programme de Klaus que je n'ai pas encore épluché on puisse se débrouiller.

Donc à suivre.

Je suis d'accord avec vous que ces fonctions Fichiers c'est pas le top. D'ailleurs ce sujet a déjà été abordé.

Moi je préfère utiliser un DLIST et travailler les fichiers dedans, et j'utilise FILE_LOAD et FILE_SAVE.

A+

Effectivement, comme tu dis, en lisant le fichier dans un Dlist on a un accès direct aux articles, c'est un substitut tout à fait valable et simple à utiliser.

Je ne veux pas enfoncer le clou pour la gestion des fichiers en panoramic, c'est vrai qu'on a une multitude de fonctions fichiers, mais on ne peut pas faire ce qu'on faisait en basic avec beaucoup moins de fonctions (textes: fichiers random à accès direct, binaire: lire tout le fichier en une seule fois dans une variable chaîne, par exemple).
Mais bon, c'est irréversible, il faut faire avec.

Il faut reconnaître aussi que panoramic n'a pas été conçu au départ pour de la gestion de fichiers, et que les fonctions qui ont été ajoutées au fil du temps l'ont été à notre demande, alors ça a été un peu décousu.

A rapprocher avec:
https://panoramic.1fr1.net/t2180-probleme-sur-lecture-de-fichier-avec-file_read
Par contre dans mon cas, il n'y a pas eu d'intervention.

Ce post-là m'avait échappé, mais ça semble effectivement le même problème, avec file_read.
Bizarrement tu lis alternativement des données ascii et binaires avec le file_read (file_read 1, a$ et file_read 1,b%), et la documentation est un peu ambiguë à ce sujet, on ne sait pas trop ce qu'il faut faire...

Les deux commandes FILEBIN_BLOCK_READ et FILEBIN_HEXA_READ marchent très bien. Dans les deux cas, la position courante est mise à jour - on peut donc lire en sequence. Et comme la commande FILEBIN_POSITION permet de forcer un positionnement dans un fichier, on peut également lire en accès direct.

Le choix entre les deux commandes de lecture se fait en fonction du type de résultat qu'on veut obtenir. FILEBIN_BLOCK_READ donne le résultat dans un tableau d'entiers, et FILEBIN_HEXA_READ donne le résultat dans une variable chaîne de caractères, sous forme de 2 caractères hexa pour chaque octet de données. Dans ce dernier cas, on utilise la fonction HEX() pour chaque groupe de 2 caractères pour reconstituer l'octet de données.

Il y a aussi les fonctions symétriques pour l'écriture.

Oui Klaus, pour les fichiers binaires il n'y a pas de problèmes, tout ça marche très bien avec les commandes FILEBIN_.

Le problème c'est la commande FILE_READ pour les fichiers Ascii, qui est censée permettre de lire des articles successifs en séquence (séparés par un 'séparateur' dont on ne sait pas trop ce que c'est: le retour-chariot/interligne ?).

Si le séparateur est bien le retour chariot interligne, je ne vois pas du tout l'intérêt de cette commande FILE_READ par rapport à FILE_READLN.

La commande FILE_READ lit, à partir de la position courante, jusqu'au prochain séparateur (fin de ligne, saut de page) comme s'il s'agissait d'un FILE_READLN. La position courante est bien mise à jour, et on peut lire en sequence. On se positionne dans un fichier texte par la commande FILE_READBUF (même si l'on doit ignorer le resultat lu, le positionnement a bien lieu). Regarde bien cet exemple:

Code:

dim a$,x%,b$
dim c$, d$, e$, f$
a$ = "aaa"
x% = 123
b$ = "bbbbb"
file_open_write 1,"x.txt"
file_write 1,a$
file_write 1,x%
file_write 1,b$
file_writeln 1,""
file_writeln 1,"essai"
file_close 1
file_open_read 1,"x.txt"
file_readbuf 1,c$,3
file_read 1,d$
file_readln 1,e$
file_readln 1,f$
message "c$="+c$+"  d$="+d$+"  e$="+e$+"  f$="+f$
end

Effectivement, ça marche comme ça, mais ça me paraît un peu nébuleux quand même !
Bon, la nuit porte conseil....

En tout cas, entre les 3 premiers file_write il n'y a aucun séparateur, autrement dit, pour relire avec file_read il faut connaître la longueur des éléments.
Mais non, même pas, puisque file_read s'arrête à la fin de ligne...

Bon je vais me coucher, ça vaudra mieux, mais en tout cas j'utiliserai autre chose que le file_read pour lire ce genre de fichier.

On rencontre le même problème dans d'autres BASICs (INPUT vs. LINE INPUT), et même dans d'autres langages comme le Pascal (READ vs READLN). La méthode la plus sûre, c'est de lire la totalité de la ligne, puis de la faire découper par le programme.

Bonjour,

Le problème avec FILE_READ c'est que la position courante n'est pas incrémentée après la lecture...
Est-ce voulu, un oubli ?

A mon avis, le seek (équivalent de FILEBIN_POSITION) n'est pas correctement géré.
Sans compter que si FILE_READLN se base sur les CRLF pour s'arrêter, logiquement pour le FILE_READ, cela devrait être le caractère de fin de chaine CHR$(0)
ou alors il y a redondance...

Une idée : peut être qu'une fonction permettant de définir le caractère de fin serait intéressante : imaginons un fichier de base de données dont le séparateur serait un '#' ou un '|'... cela simplifierait la vie pour récupérer les données...

C'est ce que je pensais au départ, qu'on pouvait définir soi-même le séparateur d'articles (par exemple ';' comme un fichier csv, ou 0 comme tu dis Nardo).
Sinon, si c'est d'office le saut de ligne, je ne vois aucun intérêt par rapport au File_Readln.
Et en plus ça ne marche pas, puisque le pointeur n'est pas incrémenté.
Donc aucun intérêt, jusqu'à preuve du contraire.
On prend File_Readln et on découpe soi-même comme dit jean_debord.

C'est clair que pour l'instant je ne vois pas l'utilité de cette commande...

Citation :

On prend File_Readln et on découpe soi-même comme dit jean_debord

Ce qui serait intéressant, c'est d'avoir la possibilité d'utiliser les expressions régulières dans Panoramic... c'est un outil très puissant, mais on s'éloigne peut être du langage basic comme le conçoit Jack...

Ce sera sans doute possible avec la prochaine version de Panoramic, qui devrait être basée sur FreeBASIC. Ce dernier possède des interfaces pour des bibliothèques de manipulation d'expressions régulières.

Bonjour,
Je crois qu'il serait bon de reprendre à zéro.Il y a un bug. Car cette fonction fonctionnait avant, vu que je m'en suis servi.
J'ai fait une recherche et j'ai retrouvé la version Panoramic 0.9.15.i du 22 septembre 2009.
J'ai testé ce programme:

Code:

dim b%,a%,a$
LIST 18:width 18,300:height 18,900
  if file_exists("c:\Panoramic-Init\Onglets.ini") = 1
      file_open_read 1,"c:\Panoramic-Init\Onglets.ini"
      repeat
        file_readln 1,a$
        item_add 18,a$
      until a$="$$$" or scancode =27
      file_close 1
  end_if

Voici le résultat:

Donc tout le reste c'est du bla bla bla
Il y a eu un problème depuis une des nombreuses versions et personne s'en est aperçu.
donc BUG, et Jack comme a son habitude corrigera cela.

Je n'y comprend plus rien! je viens d'essayer ce programme avec l'avant dernière version (j'ai pas encore téléchargé la dernière) et j'ai le même résultat.

Il est trop tôt, mais je devrais aller me coucher!
à Jack qui me fait dire des conneries!

Euh cosmos... je ne comprends pas bien ta démonstration, mais le problème est sur file_read et non pas sur file_readln qui lui fonctionne très bien depuis toujours.

On s'est croisé. Mais là je ne comprends plus rien.

Citation :

Bizarrement tu lis alternativement des données ascii et binaires avec le file_read (file_read 1, a$ et file_read 1,b%), et la documentation est un peu ambiguë à ce sujet, on ne sait pas trop ce qu'il faut faire...

Comme tu dis la documentation est ambiguë. Je me souviens qu'avec d'autre basic, on pouvait lire les deux.
Moi je lis: La variable V doit-être du même type que la commande d'écriture (FILE_WRITE), mais comme le fichier est un fichier texte, toute variable string peut convenir.
Ca veut dire quoi? Aparemment celà devrait plutôt être: doit-être une variable string, puisse qu'il refuse b% dans mon programme.
Normalement la lecture d'un fichier texte se comporte comme la lecture des datas, qui peuvent être mélangés. D'ailleurs on a READ pour les data, et FILE_read pour un fichier.

J'ai tenu à vérifier, car j'avais un doute, sur la méthode rapide de comparaison.
On peut très bien lire une donnée string, et une donnée numérique, comme dans les datas. Il n'y a pas de problème de ce côté là. Il faut seulement qu'il y ait une correspondance entre les données du fichier, et la demande de lecture.

Mais là où en plus ça me dépasse, c'est cette notion de séparateur:
C'est quoi le séparateur pour la lecture d'un fichier sensé ne pas en avoir, vu file_readln lit un fichier avec un séparateur!
Là j'arrète, je perds du temps. J'ai autre chose à faire.

Il faudrait envoyer des données avec write, et voir le résultat du fichier en hexadécimal. Mais pour le moment j'ai pas le temps. Là on comprendra mieux.

Encore une fois je me sauve, et il serait intellignent pour moi de ne pas répondre à la va-vite