FILEBIN

Lorsque j'avais découvert le langage panoramic, j'avais vu les
« fichiers texte » et les « fichiers binaires », et par habitude, j'avais immédiatement traduit par « fichiers à accès séquentiels » et « fichiers à accès direct ».
Ces jours-ci, j'ai pour la première fois cherché à utiliser les « fichiers binaires » et surprise, ce ne sont pas du tout des « fichiers à accès direct ». D'ailleurs, qu'est-ce que c'est exactement et à quoi ça sert, j'en reste songeur.
En vérité, on pourrait les appeler des « fichiers à accès séquentiel avec détection et contrôle de la position et détection de la longueur ». C'est un plus qui peut être utile, à l'occasion, mais (enfin, c'est ce que je crois) c'aurait été plus utile encore qu'ils soient carrément « à accès direct ».
Pour que ce soit des « fichiers à accès direct », il faudrait qu'on puisse y lire et y écrire en même temps, ce qui n'est pas du tout le cas.
Alors, finalement, je ne comprend pas très bien le but de ces « fichiers binaires » qui n'ajoutent vraiment pas grand chose aux « fichiers texte ».
Si quelqu'un a une réponse, je serais intéressé de la connaître.

Je me pose exactement la même question depuis 1987 (date à laquelle j'ai commencé à m'intéresser à la programmation). Je ne me suis jamais servi des fichiers binaires. je pense qu'il faut un minimum de connaissances pour y accéder (comme les DLL). Pour mon cas, j'ai justement choisi PANORAMIC, pour la simplicité, je n'éprouve pas le besoin d'utilser ces fichiers.
Mais comme je parle de quelque chose que je ne connais pas, je suis peut-être dans l'erreur.
A+

Je ne vois pas où est le problème avec les fichiers binaires dont je me sers couramment. En fait tout fichier, quel qu'il soit, peut être traité comme un fichier binaire (y compris les fichiers texte), c'est simplement le mode d'accès qui est binaire, c'est à dire qu'on peut lire ou écrire directement un octet à n'importe quel emplacement, en donnant son adresse (son rang, en partant de 1).

En fait c'est le mode d'accès qui change: dans un fichier séquentiel (texte par exemple), pour atteindre une donnée particulière (une chaîne de caractères) il faut lire successivement (en séquence) toutes les données qui la précèdent.
Les données étant séparées par des '&0D0A' (retour chariot interligne).

Dans un fichier binaire il n'y a pas de séparateurs de données, on va chercher une donnée particulière (un octet ou un groupe d'octets) en donnant simplement son adresse.
En Panoramic, contrairement au QBasic, il faut ouvrir le fichier soit en lecture, soit en écriture:
FILEBIN_OPEN_READ N,fichier$
FILEBIN_OPEN_WRITE N,fichier$
puis effectuer la lecture ou l'écriture d'un octet à la position courante:
FILEBIN_READ N,valeur
FILEBIN_WRITE N,valeur
La position courante est 1 au départ, et augmente de 1 à chaque opération.
On peut lire la position courante: FILEBIN_POS(N) ou l'imposer: FILEBIN_POSITION N,pos

Contrairement au QBasic, on ne peut lire ou écrire qu'un octet à la fois en donnant une valeur entière ou réelle (ce que je regrette vivement).

Pour mémoire, en QBasic on ouvrait le fichier en mode binaire, et on pouvait y lire ou écrire (GET et PUT) une valeur Ascii d'un nombre de caractères choisi:
OPEN fichier$ FOR BINARY AS #N
a$ = SPACE$(10)
GET #N, adresse, a$: 'lecture de 10 octets successifs dans a$
ou a$ = chr$(5) + chr$(9) + chr$(255)
PUT #N, adresse, a$: 'écriture des valeurs 5, 9 et 255 à l'emplacement adresse, adresse+1 et adresse+2.

PS pour exemple, voir le post https://panoramic.1fr1.net/vos-sources-vos-utilitaires-a-partager-f2/fonction-file_writebuf-creation-d-un-fichier-bmp-t36.htm?sid=1f83b6213688b89f053259d37d1f0eff

JL35,
merci pour ces explications, Je vais me pencher sur la question, car il me semble que la gestion des fichiers par ce mode est peut-être finalement plus simple.
A+

Bien sûr qu'on peut tout faire avec tout, mais ça fait des longs programmes, et ce serait tout de même plus simple si Jack (quand il en sera là dans son programme de travail) nous créait un véritable type de fichiers différent des fichiers plus ou moins séquentiels qu'on a, même si on peut y accéder par POSITION. Il pourrait y ajouter des GET et des PUT, et aussi des FIELD pour affecter des champs.
Mais ce qui manque surtout, c'est que les fichiers soient en lecture/écriture avec non pas FILEBIN_OPEN_WRITE (ou READ), mais FILEBIN_OPEN tout court. Cela éviterait de lire tout le fichier et de le recopier ensuite entièrement avec la modification qu'on veut faire. Il suffirait de modifier juste la partie correspondante sans que ça touche au reste. Là, ce serait un immense progrès par rapport à l'actuel, et ça se ferait seulement en quelques lignes de code.
Et puisqu'on est dans la rubique « souhaits d'amélioration », eh bien voilà un nouveau souhait.
NB : réponse à Jean Claude :
Les fichiers à accès direct sont un peu comme des variables tableau situées directement sur disque dur, on y cherche la position de ce qu'on veut trouver, et une fois trouvée, on peut modifier la donnée (par exemple, le n° de tél de Dupont).
Ici, les fichiers binaires semblent être des fichiers texte améliorés. Pour faire cela, il faut ouvrir en lecture, chercher la position, refermer, puis ouvrir 2 fichiers, l'un en lecture, l'autre en écriture, et copier l'un dans l'autre en modifiant ce qu'on copie à la position trouvée, tout refermer, supprimer l'ancien fichier (lu) et enfin renommer le nouveau (écrit). (Si on cherche à ne modifier qu'un élément, avec filebin_open_write, ça efface tout le reste).
Pour résumer simplement, les fichiers à accès séquentiels sont des données à la queue-leu-leu dont on ne peut prévoir à l'avance la longueur. Dans les fichiers à accès direct, les données à inscrire sont de dimensions constantes (par exemple 15 espaces pour le nom, idem pour le prénom, (et tant pis pour ceux qui les ont à rallonge) 10 espaces pour la date de naissance, 10 espaces pour le n° de tél...), ce qui permet des possibilités d'action plus rapides.

Tu peux très bien gérer ça en mode binaire, puisque tu connais la longueur exacte de chaque enregistrement (15+15+10+10... = mettons 80), tu connais l'emplacement exact d'un enregistrement donné, et là tu lis dans une boucle tes 80 octets successivement.
Pareil pour l'écriture.

Mais je le répète, dommage qu'on ne puisse pas lire (ou écrire) ces 80 octets d'un coup, en une seule lecture, comme en QBasic.
Et aussi, comme tu dis, qu'on soit obligé d'ouvrir d'abord en lecture, de fermer, et de réouvrir en écriture.

Ah tiens j'ai un doute en te relisant jjn4: on ne peut pas modifier un seul octet donné du fichier sans détruire le reste ? voilà qui serait bien fâcheux !
Je vérifie.

BON SANG TU AS RAISON jjn4 ! si on écrit un octet quelconque dans un emplacement quelconque d'un fichier binaire on détruit tout le fichier ! Ca alors je l'ignorais, et c'est vachement dangereux, on a vite fait de ficher en l'air un fichier si on ne fait pas gaffe à ça !
(nb les adresses partent de 0, et non de 1 comme en QBasic)
Voilà mon test:

Code:

dim f$, v, n

f$ = "Z:\Lorem.txt"
Rem *** lecture de l'octet à la position 10 du fichier
n = 1
filebin_open_read n, f$
Filebin_Position n, 10
Filebin_Read n, v
print str$(v): rem *** affichage de 115 (=&h73)
filebin_close n

Rem *** réécriture d'un autre octet à la même position 10 du fichier
n = 1
v= 160: rem *** =&hA0
filebin_open_write n, f$
filebin_Position n, 10
Filebin_Write n, v
filebin_close n
wait 3000
terminate

Le début du fichier (en hexa) au moment de la lecture:


Et le fichier (ce qu'il en reste) après écriture d'UN octet:


En fait, le FILEBIN_OPEN_WRITE commence par créér un nouveau fichier, vide (Je sais, c'est bien précisé dans la doc). Il faudrait une commande spéciale pour ça, non ambiguë, genre FILEBIN_OPEN_CREATE, et pouvoir modifier (patcher) un fichier existant.
Pour moi c'est un comportement complètement anormal et très dangereux ! Jack, au secours !

Je vous explique en deux mots ma méthode

Je fais d'abord un prog "INSTALL" pour créer le fichier avec une ligne vide
comme suit

Code:

file_open_write 1,"fichier.fic"
file_writeln 1,""
file_close 1
rem ce code ne sert qu'une seule fois
terminate

Ensuite dans le programme principale je bascule le contenu de "fichier.fic" dans un DLIST avec FILE_ADD N,"fichier.fic"
le programme travaille sur les éléments du DLIST
Et à la fin il enregistre le fichier modifié par FILE_SAVE N,"fichier.fic"
dans les 2 commandes de fichier N est le numéro du DLIST

Avec cette méthode, les noms de variables importe peut et leur nombre est limitées, du fait que c'est le N° de ligne dans le fichier qui sert d'adresse et qu'il n'y a qu'un élément par ligne. (Certe il vaut mieux avoir un petit bloc-note pour noter ce qui se trouve à la ligne x du fichier F)
Pour gérer les éléments dans le DLIST, il faut utiliser la panoplie des ITEM_??? (comme ITEM_ADD) et aussi COUNT pour le nombre d'éléments

A aucuns moments, dans le programme principale, je n'ouvre, ni ne ferme un fichier.

A+ J'ajoute que pendant la construction du programme principale vous enlevez le D de DLIST, ainsi vous visualisez le contenu du fichier avant de l'enregistrer. Bien sur, là on est pas en binaire.

En fait...

Je n'ai jamais utiliséla commande filebin etc.

On peut effectivement faire comme le dit Jean Claude.
On peut aussi travailler de la même façon avec des variables tableau.
Mais plus on a de méthodes, mieux c'est, ça permet d'adapter à chaque cas, et c'est quand même dommage qu'on n'ait pas de vrais fichiers à accès direct.

+1
Evidemment qu'on peut toujours contourner le problème. Mais il faut déjà bien être conscient du problème, et puis tout de même, ce n'est pas normal d'avoir un accès direct en lecture et pas en écriture.

La méthode Jean Claude n'est pas applicable pour des fichiers binaires (il le dit lui-même), à la réécriture le fichier est complètement détruit.

A priori, pour le moment je ne vois pas du tout comment on peut modifier un fichier binaire existant. Si quelqu'un a une idée...

Je n'ai pas plutôt écrit ça que j'ai déjà une idée: lire le fichier à modifier octet par octet, réécrire au fur et à mesure dans un fichier temporaire, arrivé à l'octet à modifier écrire celui-ci (ou ceux-ci s'il y en a plusieurs), puis continuer en recopiant la suite.
A la fin, recopier le fichier temporaire dans le fichier d'origine.
J'essaie ça. Mais c'est bien tordu.

Voilà ma solution:

Code:

dim f$, ftemp$, v, vn, n, m, pos, taille, i

f$ = "Z:\Lorem.txt": rem *** fichier à modifier
ftemp$ = "z:\tmp": rem *** fichier temporaire

Rem *** lecture de l'octet à la position 10 du fichier
pos = 10: rem *** position de l'octet à modifier

Rem *** réécriture d'un autre octet à la même position pos du fichier
n = 1: m = 2
vn= 171: rem *** =&hAB nouvelle valeur à appliquer à l'octet pos
filebin_open_read n, f$
taille = filebin_size(n)
filebin_open_write m, ftemp$
rem *** transfert des octets qui précèdent
for i = 0 to pos - 1
    filebin_read n, v: filebin_write m, v
next i
filebin_read n, v: filebin_write m, vn: rem *** transfert de l'octet à modifier
rem *** transfert des octets qui suivent
for i = pos + 1 to taille - 1
    filebin_read n, v: filebin_write m, v
next i
filebin_close n: filebin_close m
rem *** recopie du fichier temporaire dans le fichier d'origine
filebin_open_read n, ftemp$: filebin_open_write m, f$
for i = 0 to taille - 1
    filebin_read n, v: filebin_write m, v
next i
filebin_close n: filebin_close m
file_delete ftemp$
stop
terminate

Et on obtient ça, l'octet a bien été modifié et le reste du fichier est intact:


C'est un peu lourdingue, mais ça marche et je ne vois rien d'autre pour l'instant.

PS J'édite encore un coup pour dire qu'il ne faut pas être pressé, ou que le fichier soit court: 3 minutes d'attente pour un fichier de 1,1 M ! je me crois revenu sur mon cher vieux TRS-80.
La faute à mon avis à la méthode de lecture et réécriture octet par octet, en plus à faire deux fois avec la recopie finale (j'ai essayé EXECUTE "COPY etc. " mais ça ne marche pas sans signaler d'erreur).

Si seulement on pouvait écrire un octet dans un fichier sans détruire tout le reste
Si seulement on pouvait lire et écrire par blocs et non octet par octet.
Si seulement on avait une fonction FILE_COPY (indifféremment binaire ou texte)

+1,

Je dois admettre que la gestion de fichier, est prioritaire.

Excuse moi Jack !

Je me suis demandé si les fichiers binaires fonctionnaient réellement comme des fichiers à accès séquentiels bidouillés ou si il y avait quand même une petite possibilité, et j'ai imaginé ce système. C'est encore un peu lourdingue, mais un peu moins.
Au départ, je me suis demandé ceci : si au lieu de vouloir écrire de façon ponctuelle dans un fichier binaire créé un autre jour (donc enregistré) on le recréait ce jour, est-ce qu'on pourrait y écrire de façon ponctuelle en faisant remonter le curseur en arrière, ou est-ce que ça écrierait irrémédiablement à la queue leu leu avec impossibilité de modifier ce qui a déjà été écrit ?
Et là, ça marche !
Voici un programme qui ne contient qu'un n° de téléphone (01.41.37.08.56)
Il est d'abord créé et enregistré
Ensuite, il est lu et recopié
puis des modifications sont ensuite faites dans cette copie
d'abord le 08 est changé en 15 (donc vers le milieu)
puis le 56 est changé en 27 (donc à droite de la dernière modification)
puis le 37 est changé en 92 (donc à gauche des modifications précédentes)
Bien sûr, il faut encore effacer le fichier lu et changer le nom du fichier modifié. Oui, un peu moins lourd.
Voici les 2 programmes (le premier programme sert à créer le fichier)

Code:

dim i , a$
a$="01.41.37.08.56"
filebin_open_write 1,"Agenda.bin"
 for i=1 to len(a$)
  filebin_write 1,asc(mid$(a$,i,1))
 next i
filebin_close 1

dim j , g , b
filebin_open_read 1,"Agenda.bin"
filebin_open_write 2,"Provi.tmp"
 g=filebin_size(1)
 for j=1 to g
  filebin_read 1,b
  filebin_write 2,b
 next j
 filebin_position 2,9
 filebin_write 2,49
 filebin_write 2,53
 filebin_position 2,12
 filebin_write 2,50
 filebin_write 2,55
 filebin_position 2,6
 filebin_write 2,57
 filebin_write 2,50
filebin_close 2
filebin_close 1
file_delete "Agenda.bin"
file_rename "Provi.tmp","Agenda.bin"

PS : ne cherchez pas à essayer ce n°, ce n'est pas le mien.

Pas bête, effectivement je reconnais que ta méthode est moins lourde que la mienne et je ne manquerai pas de m'en inspirer.
Mais je n'enlève rien à mes souhaits.

Citation :

On peut aussi travailler de la même façon avec des variables tableau

Pour ce qui concerne les variables tableaux, j'ai vite abandonné car dès que tu atteint un certain chiffre (je ne sais plus combien) çà plante. Je pense que c'est une question de réserve en mémoire vive, mais là je ne suis pas assez calé...
Pour des programmes avec pas trop de variables et dimensionnées à moins de 500, çà passe.

C'est vrai qu'en QB, je travaillai énormément avec des variables en tableau, et je n'ai jamais eu de problèmes. (mais je n'avais peut-être jamais dépassé les limites)

A+

N'était-ce pas du temps où tout était limité et les variables tableau à 200 ?
J'ai essayé ce programme (très simplifié, c'est vrai), ça marche :

Code:

dim a$(1200,1200)
a$(800,1100)="Bonjour"
print a$(800,1100)

Par contre, si je rajoute :

Code:

dim b(8,8,8)

Là, ça plante, trop de dimensions, il paraît
C'est effectivement dommage qu'on ne puisse en mettre plus de 2.

Et si tu ajoutes des variables tableaux pour gérer des objets, Hé Bé t'as plus de place.