Problèmes avec TFixedFormatDataSet.FileName

Version imprimable

23/05/2018, 22h23
Pierre le Grand

1 pièce(s) jointe(s)

Problèmes avec TFixedFormatDataSet.FileName

Je n'ai aucun problème à ouvrir un fichier qui se trouve à la racine du disque dur, mais si je le mets dans mes documents, le fichier refuse de s'ouvrir. J'ai effectué plusieurs tests qui confirment que en dehors de mes documents, même si ce n'est pas à la racine, tout fonctionne correctement. Remplacer mes documents par son chemin absolu depuis la racine ne règle pas le problème.

De plus, le programme est incapable de lire un fichier situé dans le même répertoire que le programme principal même en ajoutant un .\ devant le nom du fichier.

J'ai l'impression que ce composant est très peu utilisé. Jusqu'à maintenant, il ne fonctionne qu'en fournissant un chemin absolu depuis la racine avec un fichier qui n'est pas dans mes documents. Ces restrictions n'étant pas dans la documentation, quasi inexistante. En Linux, il ne fonctionne pas du tout! Il est toujours incapable d'ouvrir le fichier d'entrée quelque soit son emplacement dans /home/pierre .

Le nom de fichier doit comporter des restrictions non documentées. L'image attachée montre l'ouverture correcte du fichier e:\user\Travail\D12345678901234\yyy\k12345678901234567890\z.txt , la longueur ne semble pas causer problème. En fait, c'est l'ouverture d'une copie de z.txt situé dans le même répertoire que le fichier exécutable ou dans mes documents qui ne fonctionne pas.

Pièce jointe 382817
23/05/2018, 23h36
Jipété

Nous fournir les messages d'erreur serait un plus, parce que là,
:cristal:

hello,
avec le code suivant sous windows 10, Lazarus 1.8.2 , le fichier fpc - avec des blancs.ssx (avec 1 enregistrement) dans mes documents, je n'ai pas d'erreur :

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
{$mode objfpc}
{$h+}
program testfix;
 
uses DB,sdfdata,sysutils,lazfileutils;
 
Procedure Dotest;
 
Var
  I,Count : Integer;
 
begin
  With TFixedFormatDataSet.Create(Nil) do
    try
      FileMustExist := False;
      FileName := AppendPathDelim(GetUserDir + 'mes Documents\') + 'fpc - avec des blancs.ssx';
      Schema.Add('First Name=15');
      Schema.Add('Last Name=15');
      Schema.Add('Email=20');
      Open;
      Count:=0;
      Try
        While Not EOF do
          begin
          Inc(Count);
          Writeln('Record : ',Count);
          For I:=0 to FieldCount-1 do
            Writeln(Fields[i].FieldName,' : ',Fields[i].AsString);
          Writeln('-------------------------------')  ;
          Next;
          end;
      Finally
        Close;
      end;
    finally
      free;
    end;
end;
 
begin
  DoTest;
end.

Citation:

Record : 1
First Name : Piet
Last Name : Pompies
Email : piet@pompi
-------------------------------

Ami calmant, J.P (sans T)

24/05/2018, 00h32
Pierre le Grand

1 pièce(s) jointe(s)

Citation:

Envoyé par Jipété

Nous fournir les messages d'erreur serait un plus, parce que là,
:cristal:

Voici les messages d'erreurs. Le fichier se trouve dans le même répertoire que l'exécutable, mais il n'est pas détecté. Je comprends le message, ce que je ne comprends pas, c'est pourquoi le fichier disponible n'est pas ouvert.

Pièce jointe 382862

1 pièce(s) jointe(s)

J'ai réduit le code à sa plus simple expression et il est toujours aussi fautif. Les champs ont été définis dans l'IDE. z.ssx existe et s'ouvre facilement dans notepad. Une copie placée dans e:\ s'ouvre sans problème.

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
 
unit Unit1;
 
{$mode objfpc}{$H+}
 
interface
 
uses
  Classes, SysUtils, SdfData, db, FileUtil, Forms, Controls, Graphics, Dialogs,
  DBGrids, StdCtrls, lazfileutils;
 
type
 
  { TForm1 }
 
  TForm1 = class(TForm)
    Button1: TButton;
    DataSource1: TDataSource;
    DBGrid1: TDBGrid;
    FixedFormatDataSet1: TFixedFormatDataSet;
    procedure Button1Click(Sender: TObject);
  private
 
  public
 
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.lfm}
 
{ TForm1 }
 
procedure TForm1.Button1Click(Sender: TObject);
begin
   FixedFormatDataSet1.FileName:=AppendPathDelim(GetUserDir + 'mes Documents\') + 'z.ssx';
   TRY
      FixedFormatDataSet1.Open;
 
   except
     On E: Exception DO
        ShowMessage(E.Message);
 
   end;
end;
 
end.

24/05/2018, 16h48
FChrisF

Citation:

Envoyé par Pierre le Grand

Code:

FixedFormatDataSet1.FileName:=AppendPathDelim(GetUserDir + 'mes Documents\') + 'z.ssx';

Essayez plutôt avec:

Code:

...+ 'Documents\') ...

Enfin, avec une version 'récente' de Windows (pas sur Windows XP, par exemple).
24/05/2018, 18h50
Pierre le Grand

J'ai fini par comprendre, il y a deux problèmes dont un seul concerne Lazarus. Le résultat de la fonction GetUserDir est invalide: il donne C: comme disque, mais le vrai disque devrait être E:. De plus, le vrai répertoire est e:\user, pas c:\Users, il y a un s de trop. Finalement, la machine utilise la version anglaise de Windows et le nom du répertoire est My Documents.

Avec

Code:

NomDuFichier:='E:\user\Travail\My Documents\z.ssx';

tout fonctionne normalement.

Avec la prolifération des SSD, les ordinateurs qui réservent le SSD pour les logiciels et qui mettent les utilisateurs sur un autre disque seront de plus en plus fréquents. Le bogue dans GetUserDir est donc gênant. Je suppose que c'est un problème similaire qui empêche l'ouverture du fichier situé dans le même répertoire que le fichier exécutable.
24/05/2018, 19h44
FChrisF

Je ne suis pas certain que ce soit un bug de GetUserDir.

Comme son nom l'indique, la fonction est sensée renvoyer le répertoire utilisateur (i.e. profile folder: cf. https://www.freepascal.org/docs-html...etuserdir.html).

Et a priori (sauf manip compliquée), ce répertoire est -probablement- toujours sur "c:\users\votre_nom_utilisateur". Vous pouvez toujours faire une commande "dir %userprofile%" pour le vérifier (par exemple).

Par contre, le répertoire "MesDocuments" a semble-t-il été déplacé. Mais là, à partir du moment où le déplacement est fait par l'utilisateur, il peut être n'importe où: pourquoi pas sur "e:\goodlucktofindmyname\lol\" , par exemple ?

Mais le but de la fonction GetUserDir n'est pas de trouver ce répertoire "MesDocuments"; uniquement le répertoire utilisateur.
24/05/2018, 22h27
Pierre le Grand

Citation:

Envoyé par FChrisF

Je ne suis pas certain que ce soit un bug de GetUserDir.

Comme son nom l'indique, la fonction est sensée renvoyer le répertoire utilisateur (i.e. profile folder: cf. https://www.freepascal.org/docs-html...etuserdir.html).

Et a priori (sauf manip compliquée), ce répertoire est -probablement- toujours sur "c:\users\votre_nom_utilisateur". Vous pouvez toujours faire une commande "dir %userprofile%" pour le vérifier (par exemple).

Par contre, le répertoire "MesDocuments" a semble-t-il été déplacé. Mais là, à partir du moment où le déplacement est fait par l'utilisateur, il peut être n'importe où: pourquoi pas sur "e:\goodlucktofindmyname\lol\" , par exemple ?

Mais le but de la fonction GetUserDir n'est pas de trouver ce répertoire "MesDocuments"; uniquement le répertoire utilisateur.

Merci! Cette fonction ne retourne pas la même chose sur Windows et sur Linux.

J'ai lancé un dir %userprofile% et cela m'a dirigé vers le disque c. Effectivement, mes documents pourrait avoir été redirigé n'importe-où. C'est plus simple de déterminer le chemin vers l'exécutable avec ExtractFilePath(ParamStr(0)); et surtout, c'est plus fiable.