Problème à l'ouverture d'un fichier

Version imprimable

Bonjour,

Je m'exerce en ce moment à convertir de vieux projets Delphi en Lazarus.

Le vieux petit programme FourCC Changer (d'ailleurs quasi inutile aujourd'hui;) me paraissait un exercice facile et la conversion proprement dite était sans difficultés. Il s'agit d'ouvrir un fichier AVI DivX, de lire quatre octets de l'en-tête à partir de 70 et quatre autres à partir de BC, puis éventuellement dans une autre procédure, de modifier ces huit octets.

Mais il semble qu'il y ait une différence de gestion des fichiers entre le Delphi d'il y a quinze ans et Lazarus.

J'ai donc deux procédures, qui constituent quasi tout le programme ;) La première lit, la deuxième écrit :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 procedure TForm1.BrowseButtonClick(Sender: TObject); var F : File; S : String[4]; begin If OpenDialog1.Execute = True then Begin SetLength(S,4); {$I-} AssignFile(F,OpenDialog1.FileName); Reset(F,1); {$I+} If IOResult = 0 then Begin Seek(F,$70); BlockRead(F,S[1],4); ComboBox1.Text := S; Seek(F,$BC); BlockRead(F,S[1],4); ComboBox2.Text := S; AVIName.Text := ExtractFileName(OpenDialog1.FileName); AVIName.Hint := OpenDialog1.FileName; Button2.Enabled := True; CloseFile(F); End else Begin MessageDLG('Ouverture impossible. Lecture seule ?',mtError,[mbok],0); End; End; end; procedure TForm1.Button2Click(Sender: TObject); var F : File; S : String[4]; begin If (Length(ComboBox1.Text) = 4) and (Length(ComboBox2.Text) = 4) then Begin {$I-} AssignFile(F,OpenDialog1.FileName); Reset(F,1); {$I+} Seek(F,$70); S := ComboBox1.Text; BlockWrite(F,S[1],4); Seek(F,$BC); S := ComboBox2.Text; BlockWrite(F,S[1],4); CloseFile(F); MessageDLG('Code FourCC appliqué à ['+OpenDialog1.Filename+'].',mtInformation,[mbok],0); End else Begin MessageDLG('Le code FourCC a QUATRE caractères !',mtError,[mbok],0); End; end;
Mais sous Windows, la première procédure arrive à afficher les huit octets dans les deux ComboBox, mais m'affiche ensuite une violation d'accès. Quand je veux modifier les chaînes, j'ai droit à "Access denied".

Le même code sous Linux affiche la violation d'accès aussi, mais il arrive ensuite à écrire dans le fichier sans problème. Donc ça marche, mais avec un message d'erreur.

En consultant les discussions de ce génial forum et le wiki de Lazarus, j'ai essayé de faire ce qui y était recommandé, en ouvrant le fichier selon la même démarche, mais dans un bloc try avec {$I+}, sans amélioration, au contraire, puisque la procédure est bloquée par le même violation d'accès, mais sans affichage des huit octets dans les ComboBox.

Ça n'a rien de vital, mais ça m'intéresserait, si quelqu'un comprenait ce qui se passe…

Merci.

21/12/2014, 19h56
Roland Chastain

Bonjour ! Je ne sais pas si ça changera grand chose mais il me semble qu'il faudrait plutôt déclarer S de type string (et non pas string[4]), vu qu'on appelle ensuite la procédure SetLength().
21/12/2014, 20h47
Francois_C

Citation:

Envoyé par Roland Chastain

Bonjour ! Je ne sais pas si ça changera grand chose mais il me semble qu'il faudrait plutôt déclarer S de type string (et non pas string[4]), vu qu'on appelle ensuite la procédure SetLength().

J'ai fait un essai (sous Windows 64 bits et Ubuntu Studio 64 bits), mais ça ne change rien. L'auteur a dû vouloir réserver le moins de mémoire possible pour sa variable.

Merci tout de même.

Bopnjour,

Citation:

Envoyé par Roland Chastain

Bonjour ! Je ne sais pas si ça changera grand chose mais il me semble qu'il faudrait plutôt déclarer S de type string (et non pas string[4]), vu qu'on appelle ensuite la procédure SetLength().

Je plussoie ! ;)
Avec Delphi, String[4] est un shortstring dont la mémoire est préallouée. Utiliser SetLength ensuite est donc pour le moins inutile !

Citation:

Envoyé par Francois_C

L'auteur a dû vouloir réserver le moins de mémoire possible pour sa variable.

Je me demande si l'auteur savait ce qu'il faisait... :weird:

En effet, BlockRead renvoie également -bien qu'optionnellement- le nombre d'octets lus. Cette valeur doit être affectée à S[0] car avec un shortstring (aka string[4]), cette position contient la longueur réellement utilisé de la chaine.
Aussi, j'écrirais (sous entendu à tester :zoubi:) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 procedure TForm1.BrowseButtonClick(Sender: TObject); var F : File; S : String[4]; // Ajout N : Integer; begin If OpenDialog1.Execute = True then Begin // Inutile //SetLength(S,4); {$I-} AssignFile(F,OpenDialog1.FileName); Reset(F,1); {$I+} If IOResult = 0 then Begin Seek(F,$70); // Modification // BlockRead(F,S[1],4); BlockRead(F, S[1], 4, N); // Ajout S[0] := Chr(N); // S[0] := AnsiChar(Chr(N)); pour les Delphi 2009 + de mémoire car Chr est un widechar... ComboBox1.Text := S; Seek(F,$BC); // Modification // BlockRead(F,S[1],4); BlockRead(F, S[1], 4, N); // Ajout S[0] := Chr(N); // S[0] := AnsiChar(Chr(N)); pour les Delphi 2009 + de mémoire car Chr est un widechar... ComboBox2.Text := S; AVIName.Text := ExtractFileName(OpenDialog1.FileName); AVIName.Hint := OpenDialog1.FileName; Button2.Enabled := True; CloseFile(F); End else Begin MessageDLG('Ouverture impossible. Lecture seule ?',mtError,[mbok],0); End; End; end;

22/12/2014, 11h49
Francois_C

Merci Philippe. J'avais aussi essayé en supprimant SetLength, sans résultat, sauf que ça avait l'air de lire au-delà des quatre caractères : j'avais un cinquième caractère non-ascii à la fin des chaînes affichées dans les ComboBox lors des essais Linux.

J'ai copié-collé la proposition de modification sans avoir même à la vérifier. Pas une faute de syntaxe, ça compile du premier coup sans erreur, mais hélas, toujours la même violation d'accès...

PS : C'était du Delphi d'avant 2000 (le binaire date de 2000, j'avais légèrement modifié le code source et recompilé à mon usage en 2003). Aucune modification n'est nécessaire ici du fait que je compile en 64 bits, je pense ?
22/12/2014, 14h05
Ph. B.

Citation:

Envoyé par Francois_C

Merci Philippe. J'avais aussi essayé en supprimant SetLength, sans résultat, sauf que ça avait l'air de lire au-delà des quatre caractères : j'avais un cinquième caractère non-ascii à la fin des chaînes affichées dans les ComboBox lors des essais Linux.

J'ai copié-collé la proposition de modification sans avoir même à la vérifier. Pas une faute de syntaxe, ça compile du premier coup sans erreur, mais hélas, toujours la même violation d'accès...

Ce soir -mais pas avant;)-, je regarderai ça, j'aurai Lazarus à disposition, sous windows et Linux...

Citation:

Envoyé par Francois_C

PS : C'était du Delphi d'avant 2000 (le binaire date de 2000, j'avais légèrement modifié le code source et recompilé à mon usage en 2003). Aucune modification n'est nécessaire ici du fait que je compile en 64 bits, je pense ?

Pas sur, les chaines "string" sous Lazarus sont de type utf8 et non ansi comme avec les versions de Delphi jusqu'à 2007 inclus; cela a peut-être une influence...
22/12/2014, 17h16
jurassic pork

hello,
tu as essayé en lazarus 32 bits ? parce qu'il peut y avoir des problèmes en 64 bits avec l'alignement des données.

Ami calmant J.P
22/12/2014, 19h12
Francois_C

Citation:

Envoyé par jurassic pork

hello,
tu as essayé en lazarus 32 bits ? parce qu'il peut y avoir des problèmes en 64 bits avec l'alignement des données.

Ami calmant J.P

Je n'ai pas de Lazarus 32 bits installé. Mais en effet quand je veux télécharger une mise à jour, la version 32 bits est conseillée pour Windows jusqu'à une nouvelle version du Free Pascal, même pour compiler du 64 bits :

« Please be aware that all current Lazarus 1.x releases use FPC 2.6.x. FPC 2.6.x (and probably earlier versions as well) does not properly support Windows 64 bit. Therefore, please use the 32 bit Lazarus IDE on Win64. If it is absolutely necessary to build 64 bit executables (e.g. explorer extensions), please install the 64 bit cross compiler add on for the 32 bit IDE. »

Il va falloir peut-être que j'y passe. D'ailleurs sous Linux 64, avec une version plus récente que la 1.0.14 que j'ai sous Windows, le logiciel marche si l'on méprise l'avertissement – toujours stressant quand même – sur la violation d'accès.

La question des chaînes UTF8 et de l'alignement des données me tracassait aussi.

J'ai d'ailleurs une autre question en réserve pour quand celle-ci sera résolue ;)

Citation:

Envoyé par Ph. B.

Ce soir -mais pas avant;)-, je regarderai ça, j'aurai Lazarus à disposition, sous windows et Linux...

Pas sur, les chaines "string" sous Lazarus sont de type utf8 et non ansi comme avec les versions de Delphi jusqu'à 2007 inclus; cela a peut-être une influence...

Merci, Philippe, de prendre en compte mes petits problèmes. Faut-il cocher "utiliser les chaînes ANSI" ou non ?

Bonsoir.

As-tu essayé avec un TFileStream ?

Du genre...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
procedure TForm1.BrowseButtonClick(Sender: TObject);
var
   Stream: TFileStream;
   S: string;
begin
    if OpenDialog1.execute then
    begin
        Stream:= TFileStream.Create(OpenDialog1.FileName, fmOpenRead);
        Stream.Position:= $70;
        SetLength(S, 4);
        Stream.ReadBuffer(S[1],4);
        ComboBox1.Text:= S;
        Stream.Free;
    end;
end;

Mais testé uniquement sous Lazarus 32 bits.

Cordialement
Thierry

22/12/2014, 22h27
e-ric

Salut à tous.

J'ai recréé une fiche avec les boutons et repris le code et... ça marche parfaitement avec un divx pris au hasard
Ma config : Debian 7.7 64bits + Lazarus 1.2.6
Je n'ai pas essayé sous Windows.

Va falloir déboguer + en détails pour découvrir où est déclenchée l'erreur.

@ThWilliam: c'est sans doute une idée plus pérenne, les BlockRead/BlockWrite, c'est un peu Old fashioned. Les TStream sont + intéressants mais comme on est parti sur le duo infernal, on continue ;)

Cdlt
22/12/2014, 23h45
Jipété

Citation:

Envoyé par e-ric

J'ai recréé une fiche avec les boutons et repris le code et... ça marche parfaitement avec un divx pris au hasard
Ma config : Debian 7.7 64bits + Lazarus 1.2.6
Je n'ai pas essayé sous Windows.

Idem avec Debian 7 32 bits + Lazarus 1.0.10 -- J'ai juste supprimé les 2 BlockWrite, histoire de pas risquer de casser mon fichier. ;)
22/12/2014, 23h46
Ph. B.
Au temps pour moi ! :?
J'ai regardé plus en détails l'aide de Lazarus et le code initial est tout à fait valide.
Il y est notamment dit :

Citation:

For short strings, the length is stored in the character at index 0. Old Turbo Pascal code relies on this, and it is implemented similarly in Free Pascal. Despite this, to write portable code, it is best to set the length of a shortstring with the SetLength call, and to retrieve it with the Length call. These functions will always work, whatever the internal representation of the shortstrings or other strings in use: this allows easy switching between the various string types.

J'ai également testé :
- sous win8.1 64 bits avec Lazarus 1.2.6 32 bits, RAS, pas d'erreur...
- sous XUbuntu 14.04 64 bits avec Lazarus 1.2.4 64 bits, RAS, pas d'erreur...
Je pencherais pour un problème de compilation 64 bits sous windows. Mieux vaut passer par la compilation croisée 32-64, comme conseillé...

@ThWilliam
J'avais l'intention d'essayer avec StreamRead qui me semblait en effet plus adapté à ce type de fichier, si j'en juge par ce qui est dit là :
http://wiki.freepascal.org/File_Handling_In_Pascal/fr
J'ai donc fait comme toi :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 procedure TForm1.BrowseButtonClick(Sender: TObject); var Stream: TFileStream; S: string; begin if OpenDialog1.execute then begin If IOResult = 0 then Stream:= TFileStream.Create(OpenDialog1.FileName, fmOpenRead); Stream.Position:= $70; SetLength(S, 4); Stream.ReadBuffer(S[1],4); ComboBox1.Text:= S; Stream.Position:= $BC; Stream.ReadBuffer(S[1],4); ComboBox2.Text:= S; Stream.Free; end else begin MessageDLG('Ouverture impossible. Lecture seule ?',mtError,[mbok],0); end; end;
Et paf, ça marche du premier coup encore (vous êtes quand même bons, ici !), plus de message d'erreur en effet, et le code me paraît plus sympa.

@e-ric et Jipété :

Vous arrivez à faire fonctionner le code original avec BlockRead ? (Avec Ubuntu Studio 64 14.04 LTS et le dernier Lazarus 64 bits du PPA, j'avais une violation d'accès puis ensuite ça fonctionnait) Je peux voir vos sources ?

PS : En fait tout marche parfaitement en utilisant StreamWrite pour écrire dans le fichier avec :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 procedure TForm1.Button2Click(Sender: TObject); var Stream: TFileStream; S: string; begin If (Length(ComboBox1.Text) = 4) and (Length(ComboBox2.Text) = 4) then Begin If IOResult = 0 then Stream:= TFileStream.Create(OpenDialog1.FileName, fmOpenWrite); Stream.Position:= $70; S := ComboBox1.Text; Stream.WriteBuffer(S[1],4); Stream.Position:= $BC; S := ComboBox2.Text; Stream.WriteBuffer(S[1],4); Stream.Free; MessageDLG('Code FourCC appliqué à ['+OpenDialog1.Filename+'].',mtInformation,[mbok],0); end else Begin MessageDLG('Le code FourCC a QUATRE caractères !',mtError,[mbok],0); End; end;
... Sauf que zut, après quelques essais je vois que ça ne prend pas les noms de fichiers avec accents : quelqu'un peut me rappeler comment faire ?
... Mais pour finir j'ai trouvé, tout seul pour une fois :
Code:

1 2 Edit1.Text := Utf8ToAnsi(ExtractFileName(Opendialog1.Filename)); Stream:= TFileStream.Create(Utf8ToAnsi(OpenDialog1.FileName), fmOpenRead);
Merci et bon Noël à tous.

23/12/2014, 23h51
Jipété

Citation:

Envoyé par Francois_C

@e-ric et Jipété :

Vous arrivez à faire fonctionner le code original avec BlockRead ? (Avec Ubuntu Studio 64 14.04 LTS et le dernier Lazarus 64 bits du PPA, j'avais une violation d'accès puis ensuite ça fonctionnait) Je peux voir vos sources ?

C'est bien ce que j'ai écrit, non ? Mes sources sont les tiennes, sauf que j'ai commenté BlockWrite.
24/12/2014, 11h04
ThWilliam

Bonjour.

Concernant le problème des accents :

Edit1.Text = ExtractFileName(Opendialog1.Filename); pas de conversion à faire.

Stream:= TFileStream.Create(Utf8ToSys(OpenDialog1.FileName), fmOpenRead);

Cordialement
Thierry
24/12/2014, 13h36
Francois_C

Bonjour,

@ThWilliam :

Merci pour le UTF8toSys, qui doit en effet être préférable. J'imagine que ça convertit de l'UTF8 au codage du système, et que ça laisserait plus de compatibilité pour une version compilée sous Linux ?
La conversion du Edit1.Text était la survivance d'un essai inefficace pour corriger un affichage avec des points d'interrogation au lieu des caractères avec diacritiques dans Edit1 avec le nom de fichier ; mais le passage à Utf8toSys règle tout
... mais soulève encore une question : j'ai dû ajouter LazUtf8 : est-ce que ça rend inutile une autre ressource ?

@Jipété :

C'est bien sûr ce que tu as écrit.

Mais je suis parti d'une archive où j'avais fait quelques modifications en 2003 – mais à mon avis sans toucher au pascal – et l'exécutable Delphi que j'avais compilé fonctionne toujours bien : j'avais ajouté des options aux ComboBox. Je vois qu'on trouve encore en ligne un "avic100.zip" qui semble être mon point de départ, mais vous êtes bien capables d'avoir reconstitué à partir de mon listing les déclarations et la fiche. J'ai pensé que dans ce cas il pouvait y avoir une petite différence dans les ressources, par exemple.

<mode hors sujet>
Moi aussi j'ai lutté pour l'orthographe pendant toute ma carrière jusqu'en 2008 (agrégé de lettres) ; mais les instructions ministérielles contiennent toujours une interdiction implicite d'enseigner efficacement pour ne pas risquer de fatiguer les élèves ou de fâcher les parents.
</mode hors sujet>

Merci à tous