Discussion :

[ovni76]

Bonjour,
Je suis fedora 20 en 64b avec les dernières mise à jour et j'utilise le bureau cinamon.
Sur ce bureau via les outils de cinnamon j'ai crée des icônes lanceurs d'application dont certaines développées avec lazarus.
Et voila un problème étrange
Je m'explique dans ces applications j'utilise un composant lazreport pour imprimer des données venant de tables sqlite3.
Le phénomène étrange est qu'en utilisant le lanceur du bureau la partie impression de mon application ne se déroule pas et si via le navigateur de fichiers ou depuis une console je lance la même application soit par un double clic ou une commande depuis la console
TOUT FONCTIONNE NORMALEMENT
Si je repasse sur le bureau gnome même problème mais les lanceurs sont ceux créés avec cinnamon.
Alors où est le mystère et comment le corriger.
Pour info le contenu d'un fichier d'un des lanceurs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
[Desktop Entry]
Comment=
Terminal=false
Name=auto
Exec=/home/j/Bureau/laz-linux/lazreport/preport
Type=Application
Icon=/home/j/Bureau/laz-linux/auto-sqlaz/sources/AUTO.PNG
Name[fr_FR]=report

J'ai réinstallé lazarus 1.2.2 même problème que la version 1.2.4.
Les applications fonctionnaient très bien il y a environ 2 mois, la seule chose qui peut les avoir modifiées c'est une nouvelle compilation avec lazarus 1.2.4 et son composant lazreport.
Mais c'est étrange comme comportement à croire que les éléments liés à lazreport à une réaction différentes selon la manière dont est lancé l'application comme un accès autorisé ou pas.
j'ai sérieusement besoin de lumières pour y voir plus clair.
Merci d'avance A+

[TheFreeBerga]

Bonjour,

Vraiment étrange ! La seule chose que je puisse te conseiller est de mettre des ShowMessage() un peu partout dans ton code et voir ainsi à quel moment le programme déraille. Cela pourrait aider à comprendre le pourquoi du comment.

Au fait, il s'agit bien d'un programme d'un seule tenant ? J'entends par là que, par exemple, le module d'impression qui ne fonctionne pas n'est pas un élément externe au programme principal (autre exe, dll, etc... ).

[ovni76]

bonjour,
Non lazreport est un composant se trouvant dans le dossier composant de lazarus tout comme sqlite3 mais il est vrai que la fiche principale est unique de cette application.
Pour info sous windows xp la même application fonctionne avec les adaptations de chemin pour l'accès aux données mais ne fonctionne pas sous une autre fedora en 32b avec en plus une erreur sur une donnée date au format texte et si je supprime le composant dans le document *.lrf de construction du rapport il ne disparait pas comme si les modifications n'étaient pas pris en compte à la recompilation.
Je refaire d'autres essais en reconstruisant l'ensemble avec un *.lrf nouveau est la partie impression sur une autre fiche que la principale et je donnerais les résultats.
Encore une information le fichier *.lrf peut être ouvert dans un navigateur mais c'est une langue qui m'est étrangère mais je chercherais à voir si il est modifié quand je supprime un élément comme indiqué plus haut.
Merci et A+

[TheFreeBerga]

Au regard de ton dernier message, il vient de m'arriver quelque chose de plus ou moins similaire; quand le hasard d'en mêle...
Le malheur des uns fait le bonheur des autres et je parierai que ce qui a solutionné mon problème résoudra le tien par la même occasion :

Menu Exécuter | Nettoyer les fichiers de compilation... | Nettoyer et compiler (laisser les paramètres par défaut)

Tiens moi au courant, je suis curieux de connaître le résultat...

[ovni76]

Bonsoir,
Il semble que nous n'avons pas le même problème j'ai dans le menu exécuter choisi l'option nettoyer et recompliler mais mon problème ne change pas.
Depuis mon dernier message j'ai réalisé de nouveaux essais aussi bien sur une version 32b que 64b en ayant réécrit une application complète avec une fiche principale appelant via un bouton une autre fiche avec sur cette fiche un bouton pour la prévisualisation et un autre pour l'impression en ayant ajouter un ShowMessage aux différentes séquences.
Résultats :
depuis l'EDI tout fonctionne je vois bien les différents passages avec la prévisualisation puis l'impression
depuis le bureau les mêmes messages mais pas d'affichage de la prévisualisation et en fin de séquence du lancement de l'impression une message d'erreur
List index (0) out of bounds et la suite habituelle Press OK ou Press Cancel.
Toujours très étrange et le message d'erreur ne me parle pas.
Donc A+ et encore merci pour tes recherches
Pour info je te joins mon unité impression

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
unit ureport;
 
{$mode objfpc}{$H+}
 
interface
 
uses
  Classes, SysUtils, db, Sqlite3DS, FileUtil, PrintersDlgs, LR_Class, LR_DBSet,
  LR_View, LR_PGrid, Forms, Controls, Graphics, Dialogs, StdCtrls, ExtCtrls,
  DBGrids;
 
type
 
  { TFimprime }
 
  TFimprime = class(TForm)
    Bprepare: TButton;
    Bimpression: TButton;
    Bretour: TButton;
    FrPrintGrid: TFrPrintGrid;
    Source: TDataSource;
    frDBDataSet: TfrDBDataSet;
    frPreview: TfrPreview;
    frReport: TfrReport;
    Panel1: TPanel;
    PrintDialog: TPrintDialog;
    Depense: TSqlite3Dataset;
    procedure BimpressionClick(Sender: TObject);
    procedure BprepareClick(Sender: TObject);
    procedure BretourClick(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;
 
var
  Fimprime: TFimprime;
 
implementation
 
{$R *.lfm}
 
{ TFimprime }
 
procedure TFimprime.BretourClick(Sender: TObject);
begin
  close;
end;
 
procedure TFimprime.BprepareClick(Sender: TObject);
begin
  ShowMessage('Chargement fichier');
  frReport.LoadFromFile('essai.lrf');
  ShowMessage('Le fichier est chargé');
  frReport.ShowReport;
  ShowMessage('Prévisualisation terminée');
  Bimpression.Enabled:=True;
end;
 
procedure TFimprime.BimpressionClick(Sender: TObject);
begin
  Bimpression.Enabled:=False;
  ShowMessage('Bouton impression inactif');
  Frreport.PrepareReport;
  ShowMessage('Prépare l''impression');
  Frreport.PrintPreparedReport(' ',1);
  ShowMessage('Impression terminée');
end;
 
 
 
end.

[Jipété]

Salut,

depuis le bureau les mêmes messages mais pas d'affichage de la prévisualisation et en fin de séquence du lancement de l'impression une message d'erreur
List index (0) out of bounds et la suite habituelle Press OK ou Press Cancel.
Toujours très étrange et le message d'erreur ne me parle pas.

ça, typiquement ça fait penser à une liste (StringList ou autre) dont tu penses qu'elle est remplie alors que du point de vue du logiciel elle ne l'est pas.

Maintenant, pourquoi ce comportement étrange en passant par ton raccourci, là je déclare forfait.

[tourlourou]

La seule liste qui me semble évidente en rapport avec l'impression ne serait-elle pas celle des imprimantes ? Après, pourquoi ne se remplirait-elle pas selon le lanceur ?

Ton code fait-il appel à cette liste (Printers sous Delphi et Windows) ?

[ovni76]

Merci pour vos suggestions mais pourquoi cette application fonctionne-t-elle bien depuis le menu exécuter de l'EDI et par un double clic sur le fichier exécutable via le navigateur de fichiers ou par une commande semblable via le terminal.
Après de nombreux essais effectués en 32b ou 64b j'ai l'impression qu'il y a 2 problèmes
le premier lié à l'environnement gnome3 car sous gnome ou sous cinnamon qui utilise la base de gnome.
le deuxième lié à lazreport ou à ses dépendances car depuis peu l'installation du paquet lazreport indique le chargement d'un autre composant et j'ai constaté aussi que l'utilisation d'un fichier *.lrf ancien sans repasser par le concepteur du composant frReport donné une erreur de format.
Ayant tester l'installation de la version 1.2.2 de lazarus après la désinstallation de la version 1.2.4, je vais dans les jours qui viennent fiare la même opération avec des versions plus anciennes la 1010 en version 64b et la 0931 en version 32b.
Je vous tiendrais au courant, mais si j'ai besoin d'imprimer je pourrais utiliser le lancement en direct.
Donc A+

[Ph. B.]

Bonjour,

...mais pourquoi cette application fonctionne-t-elle bien depuis le menu exécuter de l'EDI et par un double clic sur le fichier exécutable via le navigateur de fichiers ou par une commande semblable via le terminal.

Compte tenu de la manière de charger le fichier, c.a.d. en indiquant que le nom (frReport.LoadFromFile('essai.lrf');), l'application va se baser sur la valeur du répertoire courant que l'on peut obtenir avec la function GetCurrentDir.
Avec le raccourci, la valeur du répertoire courant doit être /home/nom_utilisateur alors que depuis l'EDI ou par appel via le navigateur de fichiers ou le terminal, elle doit être la même que la valeur du répertoire de l'application. Dans le 1° cas, le fichier n'est pas trouvé donc pas chargé...
2 solutions :

1. Charger le fichier rapport en indiquant un chemin absolu : frReport.LoadFromFile(ExtractFilePath(Application.ExeName) + 'essai.lrf');.
2. Incorporer le fichier rapport dans les ressources de la fiche : propriété TfrReport.StoreInForm à True lors de la conception.

[tintinux]

Bonjour

Ph.B a certainement raison, mais alors ça voudrait dire que frReport.LoadFromFile ne retourne pas une exception quand le fichier passé en paramètre n'existe pas.

Si c'est bien ça, c'est un bug qui mériterait d'être signalé...

[ovni76]

Merci de votre aide,
Le problème est bien lié à un problème de chemin pour le chargement du fichier *.lrf.
la première solution proposée pa Philippe fonctionne
mais pas la deuxième la propriété TfrReport.StoreinForm mis à True ne change rien.
C'est vrai que malgré le chemin de lancement donné par le lanceur ne suffit pas pour un chargement du fichier *.lrf.
Pour signaler le bug je laisse les spécialistes en langues étrangères le réaliser, j'ai déjà tenté l'opération sans succès faute de comprendre le mode opération.
Encore merci mais sans défaut à l'exécution difficile de trouver.
A+

[Ph. B.]

Bonjour,

mais pas la deuxième la propriété TfrReport.StoreinForm mis à True ne change rien.

Surement parce que vous n'avez pas retiré l'instruction LoadFromFile !

Elle devient inutile du moment que le rapport est inclus dans les ressources de la fiche, elle même incluse dans l'exécutable...

[ovni76]

Bonjour Philippe,
Comme j'aime comprendre je viens de tenter la deuxième modification en ayant retiré l'instruction avec le LoadFromFile : cela ne fonctionne pas.
Il doit me manquer une ou plusieurs informations.
Je suis un autodidacte pour la programmation et de plus mes neurones ne sont plus très actifs ce qui veut dire que je comprends vite mais il faut m'expliquer longtemps et avec une grande patience
Donc l'instruction a écrire pour le numéro 2 c'est l'ajout de la ligne :
FrReport.StoreInForm:=True; dans la fiche où se trouve le composant TFrReport comme ci-dessous

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
procedure TFreport.BprepareClick(Sender: TObject);
begin
  //frReport.LoadFromFile(ExtractFilePath(Application.ExeName)+'essai.lrf');
  frReport.StoreInForm:=True;
  frReport.ShowReport;
  Bprint.Enabled:=True;
end;

Mais l'instruction FrReport.ShowInForm:=True; peut être remplacée par le passage de la propriété "ShtoreInForm" de false à true via l'inspecteur d'objet

Dans le message c'est TFrReport.StoreInForm que je dois mettre à true mais avec le "T" en plus j'ai une erreur de compilation
D'autre part comment l'application va savoir quel fichier de rapport utiliser.
Ou bien la deuxième solution ne permet que d'éviter le donner le chemin complet dans la commande LoadFromFile.
Merci de me permettre d'y voir clair car pour moi c'était l'une ou l'autre qui devait résoudre mon problème.
Alors encore un petit coup de main.
A+

[tintinux]

Bonjour

Je pense que StoreInForm doit être mis à TRUE dans l'inspecteur d'objet, en même temps qu'on donne le nom du fichier, pour que ce dernier soit effectivement enregistré dans la Form.

[Ph. B.]

Bonjour Jean,

Comme j'aime comprendre je viens de tenter la deuxième modification en ayant retiré l'instruction avec le LoadFromFile : cela ne fonctionne pas.
Il doit me manquer une ou plusieurs informations.

J'aurais du être plus explicite, voila tout !
Comme il s'agit d'intégrer le rapport dans les ressources de la fiche, il faut donc le faire en mode conception, donc initialiser la propriété StoreInForm à True depuis l'éditeur de propriété.
Il faudra peut-être rouvrir le rapport avec le concepteur avant de relancer la compilation.
Si le fichier est inclus, on doit le voir en ouvrant le fichier *.lfm correspondant à l'unité de la fiche où se trouve le composant frReport.
On doit avoir un code similaire à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
object Freport: TFreport
...
  object frReport: TfrReport
    InitialZoom = pzDefault
    Options = []
    PreviewButtons = [pbZoom, pbLoad, pbSave, pbPrint, pbFind, pbHelp, pbExit]
    StoreInForm = True
    DataType = dtDataSet
    left = 320
    top = 8
    ReportXML = '<?xml version="1.0" encoding="utf-8"?>'#10'<CONFIG>'#10'  <LazReport>'#10'  ...  </LazReport>'#10'</CONFIG>'#10
  end
...
end

D'autre part comment l'application va savoir quel fichier de rapport utiliser.

Quand le rapport est inclus dans les ressources de la fiche, il n'y a plus besoin de fichier. Le concepteur sait qu'il doit aller charger le rapport en lisant les ressources de la fiche.
Si l'on a pas fait une copie de ce rapport dans un fichier et que l'on passe la propriété StoreInForm à False, on ne perd pas tout, le concepteur conserve une copie du rapport.

[ovni76]

Merci Phillipe,
Comme cela c'est bon, dans mon essai précédent je n'avais peut-être pas recompiler l'appli.
Pour répondre à Tintinux, le fichier du rapport est incorporé avec cette méthode dans le fichier *.lfm ce qui est plus facile mais peu augmenter la taille de l'exécutable mais là c'est des suppositions.
Mais voila un problème résolu est une augmentation de mes connaissances.
Encore merci pour votre aide.
A+