Conversion de fichiers de longueur fixe
Bonjour,
Je suis en train de convertir du vieux VB4 en VB.Net.
Trouver les différences de programmation est du boulot, mais avec toutes les aides comme ce forum, on finit par y arriver.
Il reste une partie obscure : la gestion de fichiers. Car, c'est bien beau de pouvoir écrire un nouveau programme qui traitera de nouvelles données, mais quand on a des GO de données accumulées pendant des années, on ne va pas tout mettre à la poubelle.
En VB4, on pouvait définir une Structure composée de champs mixtes type chaînes de longueur fixe et champs numériques de différents types. Ce que, dans le passé, on appelait une image d'enregistrement.
Avec VBNet, rien ne colle :
- les parties numériques sont interdites,
- les longueurs d'enregistrements ne collent pas, car en fait, il faut ajouter une partie longueur cachée de 2 octets devant chaque chaîne, alors qu'on ne la définit pas. Mais elle est bien présente et on doit, par exemple, l'inclure quand on fait du Random sur le fichier en accès binaire.
Cas simple : (index d'accès à un gros fichier, converti)
Code:
1
2
3
4
5
6
|
Structure x
z1 As String ' longueur 1
z2 As String ' valeur numérique éditée via Format !, longueur 8
z3 As String ' longueur 1
End Structure |
Pour simplifier, disons que je peux ensuite accéder à x.z1, x.z2, etc.
Pour accéder à ce fichier en Random, je dois le définir en longueur 16, chacun des 3 strings ayant été précédé d'une partie longueur :
2+1 + 2+8 + 2+1 = 16 'caractères'
Globalement, mon petit fichier index de 4 octets par 'ligne' a donc été multiplié par 4. (z2 était du int16 auparavant)
Pour des fichiers plus gros, avec plein de 'z', mes choix ne sont pas faits ...
L'image du fichier, tel qu'elle est sur le disque est donc :
Code:
1
2
3
4
5
6
7
8
9
|
(Structure) ' la réalité du fichier disque !
lz1 As Int16 ' 2 octets avec le low-order byte d'abord
z1 As String ' longueur 1
lz2 As Int16 ' 2 octets avec le low-order byte d'abord
z2 As String ' valeur numérique éditée via Format, longueur 8
lz3 As Int16 ' 2 octets avec le low-order byte d'abord
z3 As String ' longueur 1
(End Structure) |
Du coup, après, je peux transformer mon z2 en ULong pour la lecture en random de la grosse table. Et ça fonctionne !
Mais j'ai quand même de grosses questions :
1. Y a-t-il un moyen plus élégant de stocker du numérique dans une structure ?
2. Que peut-il se passer si, pour une raison ou une autre, les chaînes z1 ou z3 se mettent à contenir des valeurs sur 2 à 6 octets ?
Par exemple, j'ai traduit un "é" d'un fichier VB4. Il est représenté par X'E9'. Dans un fichier texte créé par une application C++, j'ai écrit un autre "é" qui est, cette fois, représenté par X'C3A9'. Tout cela sur le même ordinateur et avec le même Windows, vision hexa des fichiers via EditHexa.
Si, par exemple, lz3 grandit et que z3 s'allonge, mon découpage par 16 octets de la lecture Random sera décalé. Faut-il en plus que je vérifie que la longueur du string n'est pas différente de ce que j'attend ou le 'système' peut-il tronquer (sur quelle base ?).
Donc si l'un des participants a eu des expériences (VB4 est quand même bien vieux, (comme moi !) mais ça fonctionne super depuis des années) ...
Merci.
-------------- Fin provisoire des questions (lol)
Pour ceux que ça intéresse, les fonctions déjà au point pour cette conversion sont :
- Récupération et contrôle de paramètres d'entrée en Windows Form (avec un main à part)
- Système de gestion de la position des formes d'une application selon les choix 'souris' de l'utilisateur. (juste une sauvegarde des coordonnées dans un fichier texte, rien de miraculeux ...).
- En cours : Gestion de paramètres externes via un fichier texte type .INI. Fait en C++ 2005, à convertir en VB.Net.
