Bonjour,
A mon avis la gestion des images ne justifie pas l'abandon de LazReport. Seule l'impossibilité actuelle de gérer les Rich Text Objects est une vraie lacune. Il y aussi un petit bug mais corrigeable sur les code-barres (et évidemment les plus usuels).
La solution à votre problème en LazReport est la même que l'affichage d'un Blob-image dans une StringGrid : il faut utiliser les Streams. Et Lazarus est très performant à ce niveau.
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
|
procedure TForm1.Button2Click(Sender: TObject);
begin
with sqlquery2 do try
Close;
with SQL, Params do begin
Clear;
SQL.Text := 'SELECT teid, tenom, teimage FROM test2013;';
Open;
end;
finally
//
end;
end;
procedure TForm1.frReport1EnterRect(Memo: TStringList; View: TfrView);
var
imgPrt: TStream;
begin
if View.Name = 'Picture1' then begin
imgPrt := TMemoryStream.Create;
TFrPictureView(View).Picture.Clear;
imgPrt:=sqlquery2.CreateBlobStream(sqlquery2.FieldByName('teimage'), bmRead);
TFrPictureView(View).Picture.LoadFromStream(imgPrt);
imgPrt.Free;
end;
end; |
Voici le résultat.
Je mets à disposition le code source d'un petit démonstrateur avec une base importante de 10000 enregistrements pour souligner la performance des streams en Lazarus et celle de LazReport (455 pages en preview en moins de 3 secondes !). Le projet "semble" fonctionner : j'ai dû débrancher le debugger de Lazarus. Mon Qt5 utilise une version trop récente de MinGW et cela dérange Lazarus 
. -> Si vous rencontrez un problème de compilation, n'hésitez pas à me le faire savoir.
J'ai placé les dll sqlite 32 et 64 dans des sous-dossiers. Par défaut, c'est la win 32 qui est installée.
J'ai testé également FortesReport... Enfin peu finalement. J'ai décidé de ne pas le retenir. Le Portugais, je ne connais pas. La doc anglaise est peu abondante. Il y a en effet "plein" de versions qui trainent un peu partout sur le web et une ou deux qui s'installent en Win32. Je n'ai pas essayé en 64 bits. Les forums sont "anciens" comme les dernières mises à jour du produit [2011]. En attendant, comme j'aurais aimé tester la gestion des Rich Text Objects, j'ai relancé les éditeurs de FastReport4 mais sans espoir, c'est la troisième tentative en un mois ou 2.
-----------------------------
Addendum : 18:00
Pour être complet, je termine aujourd'hui mon étude commencée il y a 6 mois de Qt (4 puis 5), justement avec le choix d'un générateur d'états. En la matière, voici ce qu'il manque à Lazarus :
J'ai fait cela en 10 minutes chrono après le téléchargement de la version d'essai... Je n'ai écrit aucun code sauf le nom de la base de données et la requête de sélection utilisés dans le code Lazarus ci-dessus. J'ai modifié le premier tenom de la base test2013 pour en faire un champ HTML. La prévisualisation est un peu plus longue, 8 s (cf en bas de l'image) contre 3 en Lazarus... pour un volume de plus de 400 pages. Le code n'est donc pas optimisé : c'est une version de démonstration. La prise en main pour un Lazarusien est instantanée. C'est NCReport en version Qt 5.1. Cela fonctionne sous Win et Nux et probablement Mac mais je n'en ai pas sous la main. Je testerai demain au lycée.
Qu'est ce que je peux exprimer ? - Le prix de NCReport est modique (équivalent de celui de FastReport 4) et la version d'essai existe alors que pour FastReport4, je n'arrive pas à savoir si la version commerciale est disponible bien que "présente" (ie référencée) sur le site de l'éditeur !
- Qt5 vient de sortir et la mise à jour de NCReport aussi pour tous les OS... avec cette réflexion supplémentaire que Qt5 existe aussi en (L)GPL même s'il existe une version commerciale. Mais qui achèterait actuellement une version commerciale de Lazarus ?
- Cela gère les champs HTML (et donc RTF car on trouve de nombreuses bibliothèques de conversions en C++) sans aucune difficulté et les images aussi
- La prévisualisation est un peu moins rapide que celle avec Lazarus mais il faudrait voir s'il y a moyen de rentrer dans le code et de l'optimiser
- La conception du même rapport (au HTML/RTF près) avec Lazarus ne nécessite pas beaucoup de code et resterait dans le coup si leur équipe de développement voulait un peu écouter les utilisateurs et leurs besoins d'autant qu'initialement la base de Lazreport est un clone de FastReport qui lui gère les champs HTML (ou RTF)... J'ai réalisé aussi un utilitaire de conversion RTF<->HTML en Lazarus pour les codes simples.
- LazReport n'est pas plus difficile d'accès que NCReport. C'est équivalent à mon sens.
Mais surtout, je peux exprimer des regrets à l'encontre de Lazarus au terme de cette étude. Lazarus est figé dans le monde du développement dont il ne suit pas le fil et surtout la rapidité de l'évolution.
Certes, faute de moyens... et donc, dans ce genre de situation, il faudrait peut-être diminuer la dispersion et traiter les urgences :- Pour être réellement portable, des wrappers propres sur les widgets usuels des 3 OS principaux (Win-Nux-OS X) en 64 bits prioritairement voire exclusivement si le temps manque, et évidemment pour Linux, en privilégiant le Gtk3. De toute façon, la gestion du Gtk2 est mauvaise. C'est donc une chance d'assainir -de reconstruire- les codes..
- Pour être réellement exploitable, les quelques types de champs de base manquants (notamment les RTF y compris dans les Grids),
- Idem pour les quelques composants un plus évolués nécessaires comme les StringGrids, les TreeViews, la gestion des gifs animés,...
- Et une remise à jour de LazReport -qui a peut-être initialement bénéficié des Rich Edit Objects- mais comme Lazarus ne connaissait ni MemoRich, ni RichEdit, ils étaient sans intérêt.
Avec cela Lazarus serait une plateforme polyvalente, attractive et pourrait porter en effet un numéro de version 1.x... Mais, il y a la réalité...
Je me donne une semaine de réflexion... sans programmer pour prendre le recul nécessaire. Mais très probablement -et même si Qt n'est pas sans problème- je quitterai ce forum pour celui de Qt... sans oublier d'y repasser périodiquement comme sur celui de Delphi.
Bonne continuation.
Cordialement. Gilles
Fortes Report : affichage images JPG
) concernant Lazreport. Les réponses m'ont convaincu qu'il ne me serait pas possible , avec la version en ligne de Lazreport d'afficher des images dont le nom du fichier était un champ de base SQLITE (ou autre certainement) ni des mémos affichant le contenu d'un fichier texte lui aussi se référant à un nom stocké dans une base alors que j'affiche cela sans trop de difficultés dans un formulaire.
Répondre avec citation
Envoyé par OR34a
Partager