Discussion :

[Higgins]

Bonjour tout le monde,

Je ne sais pas très bien dans quelle rubrique poser ma question.
J'ai développé un site web comportant une dll (64 bits) pour Apache avec Delphi Alexandria.
Une des fonctionnalités consiste à générer un rapport avec FastReport puis à l'exporter au format PDF (en utilisant leur composant tfrxPDFExport).
Le fichier pdf ainsi généré est ensuite ouvert dans un nouvel onglet du navigateur.
En mode "debug", tout va bien. Si je lance httpd.exe en mode "autonome" à partir d'un raccourci, tout va bien aussi.
En revanche, si j'installe Apache en tant que service, ça ne fonctionne plus

A priori, l'application génère bien un fichier pdf dans le dossier prévu mais il est vide.
Il n'est pas affiché dans le navigateur et quand je l'ouvre avec acrobat ou autre, j'ai une page blanche (le fichier ne fait d'ailleurs que 2Ko au lieu de 300ko environ)

J'ai pensé à un problème de droit d'accès au dossier, j'ai modifié le compte associé au service, etc.. sans succès

[ShaiLeTroll]

En service, attention à l'isolation du Bureau, FastReport VCL 3.0 fonctionne en Service, oui, c'est une assez vieille version mais même en D10, là où je suis cela n'a jamais été mis à jour semble-t-il car elle a été modifié en interne.

Cependant, c'est l'Exe qui contient FastReport qui est un Service et non une DLL.
Et même principe que toi, c'est via Apache, mais invoquer en WS, le PHP utilise des Sockets pour dialoguer avec le [Web]Service et récupère le PDF et le remonte ensuite au Browser comme un fichier téléchargé.


Pour des fichiers vides de 2Ko, je l'ai déjà vu, plusieurs niveaux de bug, où cela s'arrête juste l'entête du fichier, ou cela s'arrête à une grille vide ...
Apache, es limites de tout sont augmentés, aussi bien taille max en mémoire, taille max en retour de requête ... genre memory_limit en PHP


Si tu es en ADO, pense à CoInitialize à chaque Thread, si c'est la base qui ne fonctionne pas
Tu devrais ajouter des logs pour voir ce qui se passe.

[Higgins]

Merci pour ta réponse. Je n'avais pas envisagé que FastReport puisse avoir un comportement différemment dans une DLL
Je ne suis pas en ADO, j'utilise les composants Firedac. Malgré tout , il y a déjà un coInitialize dans chaque thread pour d'autres besoins

En ce qui concerne le fichier pdf généré, il ressemble plus à une "coquille vide" qu'à un fichier tronqué car à l'édition dans Notepad++, il semble avoir toutes les "balises" jusqu'à EOF et il s'ouvre sans erreur dans un lecteur

Je chercher du côté de FastReport. J'espère que ne n'aurais réécrire tout les rapports qui fonctionnent en client lourd pour les utiliser en mode Web...

[SergioMaster]

Bonjour,

je viens de voir ce dépôt https://github.com/antoniojmsjr/FastReportExport
peut-être sera t-il d'aucune aide mais ?

[Higgins]

Merci à tous les deux pour votre aide mais pour l'instant je n'ai pas résolu mon problème.

@ShaiLeTroll: Tu as peut-être mis le doigt (en tout bien tout honneur )sur la cause du problème

FastReport VCL 3.0 fonctionne en Service

Nous utilisons FastReport FMX Pro. S'agissant de la version Pro, la palette de composants fournis avec Delphi est désinstallée et donc.. pas de version VCL dispo pour vérifier
Je vais voirsi je peux modifier l'installation sur un poste

@SergioMaster: merci pour le lien, mais, apparemment, il se contente d'encapsuler les composants d'export de FastReport. du coup j'ai le même résultat.
En plus, c'est la VCL qui est ciblée, j'ai dû adapter le code pour FMX.
ça m'a permis de suspecter le composant frxPDFExport car avec ce dépôt, l'export se fait en deux temps:
- génération d'un flux en mémoire
- écriture du fichier uniquement si le flux est correct

Du coup , je n'ai plus l'écriture du fichier vide de 2ko. Le problème semble donc bien lié à la génération du PDF

2 infos complémentaires:
- le PDF contient des code-barres (police de caractère, pas une image) mais le problème persiste si je change la police
- lorsque je laisse les valeurs par défaut du composant frxPDFExport (compression, embeddedFonts, etc...) j'ai une erreur

Impossible de créer un objet WIC Imaging Factory pour TCustomBitmapCodecWIC

La dernière fois que j'ai eu des problème de WIC avec Delphi, c'était sur XP et Windows server 2003...... Je ne pensais pas en réentendre parler un jour

[Higgins]

Bonjour à tous,

Mon problème est (enfin) résolu ! Je partage la solution ici pour ceux qui se trouveraient dans le même cas

D'après FastReport, le problème ne viendrait pas de l'export PDF, le coupable serait Firemonkey qui utilise GDI+ pour dessiner sur le canvas mais ne l'initialise pas pour les DLL.
C'est curieux, car ma DLL fonctionne sans problème lorsque Apache est lancé en "standalone" mais bon....
Voici le code incriminé



J'ai recopié le code de la section initialization de Winapi.GDIPOBJ.pas dans mon webmoduleCreate, le code de la section Finalization dans mon WebModuleDestroy et....ça fonctionne, que ce soit en mode autonome ou en service