Discussion :

[peter27x]

Bonjour,

nous avons des appli qui tournent sans pb depuis des années sous Citrix, développées sous Delphi.
Les éditions chez les clients Citrix fonctionnaient très bien, quelques soient les versions de Delphi installées, jusqu'à peu...
Nous avons migré de XE5 à Delphi 10 Seattle, recompilé une de nos appli, et découvert que les éditions ne sortaient plus que des pages blanches, éditions bien entendu n'ayant subi aucun changement entre temps.

Si on lance le même exe directement sans passer par Citrix, l'édition s'imprime bien.

Nos éditions ont été faites sous Quick Report.

Après x tests, nous avons constaté quelque chose d'intéressant sur une édition passant par un preview :

- si on tente de l'imprimer directement (via le petit bouton d'impression du preview) : page blanche.

- si on ouvre la fenêtre de configuration de l'impression (petit bouton juste à côté de l'autre), et qu'on la referme sans rien changer (on clique directement sur le OK de la fenêtre de configuration), et que l'on clique alors sur le petit bouton d'impression : l'impression est OK...

Nous n'avons pas encore trouvé d'où cela peut venir, mais cela fait penser à un pb de détection de l'imprimante par défaut sous Citrix quand l'exe a été compilé sous Seattle...

L'ennui c'est que si ça vient de là, la solution consistant à forcer cette détection par le code nous obligerait à aller faire cette modif dans toutes les éditions de toutes nos applications, et y'en a des tartines...

Toute aide sera la bienvenue...

Merci.

[peter27x]

Re-bonjour à tous,

nous avons réussi à isoler l'origine du problème, car lors du passage de XE5 à Seattle, nous avions aussi du passer de QR5.06.0 à QR5.06.2 (Quick Report, pour cause de compatibilité avec Seattle).

Or, le test suivant a permis de déterminer que c'était QR5.06.2 le "responsable" du bug : en installant QR5.06.2 sur XE5, et en recompilant un exe dans cette config : le problème est présent (page blanche).

Le même exe avec QR5.06.0 (sur XE5 donc) : pas de problème d'impression...

Seattle est donc "clean", c'est Quick Report 5.06.2 qui apporte ce problème...

Si cela peut permettre à certains d'entre vous de nous apporter une solution...

Pour info je rappelle une particularité du problème déjà évoquée dans mon premier post :

Après x tests, nous avons constaté quelque chose d'intéressant sur une édition passant par un preview :

- si on tente de l'imprimer directement (via le petit bouton d'impression du preview) : page blanche.

- si on ouvre la fenêtre de configuration de l'impression (petit bouton juste à côté de l'autre), et qu'on la referme sans rien changer (on clique directement sur le OK de la fenêtre de configuration), et que l'on clique alors sur le petit bouton d'impression : l'impression est OK...

Et je tiens à préciser que le problème est identique que l'on passe par une véritable imprimante ou bien par PDFCreator (comme imprimante par défaut)... Le pdf généré sera blanc exactement comme sur une imprimante physique si l'on ne passe pas par la configuration de l'impression...

Merci à ceux qui m'auront lu jusqu'au bout...

[Andnotor]

Ca donne l'impression que tu imprimes sur une page de taille 0/0.
Dans ton test, essaye simplement de faire un Printer.Refresh avant impression.

Bien que pas lié à l'impression, j'avais eu un problème un peu similaire avec certains outils de prise de contrôle à distance (pcAnywhere, NetSupport) qui me retournaient une taille d'écran de 0/0. Appeler Monitor (ou Screen.GetMonitors) de la fiche suffisait à régénérer les données d'écran.

[peter27x]

Ca donne l'impression que tu imprimes sur une page de taille 0/0.
Dans ton test, essaye simplement de faire un Printer.Refresh avant impression.

Bien que pas lié à l'impression, j'avais eu un problème un peu similaire avec certains outils de prise de contrôle à distance (pcAnywhere, NetSupport) qui me retournaient une taille d'écran de 0/0. Appeler Monitor (ou Screen.GetMonitors) de la fiche suffisait à régénérer les données d'écran.

Merci je vais tester ta proposition.

[peter27x]

Ca donne l'impression que tu imprimes sur une page de taille 0/0.
Dans ton test, essaye simplement de faire un Printer.Refresh avant impression.

Bien que pas lié à l'impression, j'avais eu un problème un peu similaire avec certains outils de prise de contrôle à distance (pcAnywhere, NetSupport) qui me retournaient une taille d'écran de 0/0. Appeler Monitor (ou Screen.GetMonitors) de la fiche suffisait à régénérer les données d'écran.

Bon et bien ça ne marche pas, aucune différence... à savoir qu'on on a toujours le report qui s'affiche bien au niveau du preview, mais page blanche à l'impression de ce dernier...

Nous continuons à chercher...

[peter27x]

Un début de solution (qui nous obligera à modifier TOUS les reports de TOUTES nos applis par contre) :

simuler le fait de passer par l'écran de configuration de l'impression (comme déjà indiqué dans le sujet initial) :

Pour cela on va mettre un bout de code tout bête dans l'événement "OnApplyPrinterSettings" du report :

Code :

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

1
2
3
4
procedure TMonReport.QuickRepApplyPrinterSettings(Sender: TObject; var Cancel: Boolean; DevMode: Pointer);
begin
  MonReport.PrinterSettings.ApplySettings(MonReport.QRPrinter);  // fonctionne mais on perd le titre du report (et surement toutes les autres propriétés)
end;

Comme indiqué dans le commentaire on perd les infos propres au report (son titre notamment) : MAIS CA RÉSOUT LE PROBLÈME...
(le titre devient tout bêtement "Citrix EMF universal print job"...).

Nous allons voir si on peut pas garder les infos du report (titre, etc...) lors de cette simulation de config d'impression... ça doit pas être bien méchant, mais si quelqu'un avait la réponse ça nous ferait gagner du temps...

A noter que la solution fonctionne que l'on passe par un preview ou pas... (heureusement, la plupart de nos éditions n'ont pas de preview...).

Pour le reste, il semblerait que ce cas soit un bug connu de Q.R. sous Citrix... non encore solutionné... on risque donc de devoir se contenter de ce pansement "maison" pour le moment...

[Edit] : comme je le craignais la perte du titre du report est synonyme de perte de toutes les autres propriétés, et notamment de l'orientation de ce dernier... donc un report défini en paysage sortira en portrait (mode par défaut des imprimantes en général), reprendre une à une les propriétés de report me semble facile à coder (et bien non ça n'est pas si simple bizarrement... !), mais n'y aurait il pas une solution plus simple et surtout plus propre ?

[mballasse]

Bonjour,

Je rencontre exactement le même problème suite au passage de Delphi XE6 QuickReport 5.06 Build 4 compilation 32 Bits à Delphi 10.3.3 compilation 64 bits QuickReport 6 Pro Build 4.25
Apres de nombreux tests Delphi 10.3.3 n'est pas en cause ni la passage de la compilation 32 à 64 bits.

Je vais essayer de comparer tous les fichiers sources QuickReport entre la version 5.06 Build 4 et 6 Pro Build 4.25 afin de trouver les différences

[SergioMaster]

Je n'utilise plus Quickreport (ou plutôt, je suis en train de migrer tous mes états QuickReport 3 vers FastReport) mais je me souviens d'un bug qui était récurrent dans les versions que j'ai utilisé :
le problème de l'imprimante par défaut. Dès qu'il n'y en avait pas de définie, des choses étranges se passaient. Un problème de ce genre est-il envisageable ?