Cela fait quelques temps que je recherche un moyen d'éditer des reports avec
.NET
J'ai besoin d'un outil qui se base sur un template facilement modifiable via
interface graphique, tel que Crystal Reports.
Mais aussi qui supporte en entrée :
- Un DataTable pour les données, et non une connexion autonome à une base de
données base
- Des images dynamiques chargées à partir d'un chemin d'accès provenant de
la source de données
- L'impression, la prévisualisation (et l'export en PDF si possible)
- La mise en forme au millimètre prêt (génération de fiches produits à
installer dans des magasins, je peux pas faire un truc tout pourri)
La version de Crystal Reports livrée avec Visual Studio 2005 n'offre pas la
possibilité de charger une image dynamiquement à partir d'un chemin d'accès
provenant de la source de données (c'est disponible dans la version payante
cependant. La MSDN annonce un patch "en début 2007" permettant de corriger
cette lacune, mais pas moyen de trouver la moindre trace d'une mise à jour,
ni sur Microsoft Downloads ni sur le site de BO).
Même limitation avec Microsoft Reporting Services qui est aussi disponible
avec VS 2005.
Seul problème, les éditions sont générées à partir d'un programme client,
qui doit être déployé dans environ 120 magasins, et fourni gratuitement par
la centrale d'achat.
Pour cette raison il est totalement impossible de fournir une version
payante de Crystal Reports, cela coûterait bien trop cher !
J'avais fini par trouver un outil gratuit "MyNeoReport", qui est un clône
assez bien foutu de Crystal Report, et qui permet de faire tout ce dont j'ai
besoin.
http://www.devbox4.net/?q=myneoreport
Seul hic, il est très peut documenté, et je ne sais pas ce qui est arrivé à
l'auteur, mais son site ne fonctionne pas, et pas moyen de le contacter.
J'ai commencé à faire des tests, et ça marche plutôt bien, à un détail
près... L'utilisation d'une image dynamique... (évidement...)
Le type "DataImage" est buggé, et la propriété "UseImagePath" ne fonctionne
pas (exactement pareil que CR livré avec Visual Studio, arf !)
J'ai donc dû bidouiller, en utilisant un objet "Image" et un bloc de script
dans le "BeforePrint" de ce dernier (ce script erst embarqué dans le report,
je n'ai donc pas d'intellisense, c'est un peu le jeu de la denivette pour
trouver le nom des classes et objets disponibles...) :
Ca marche vraiment très bien, c'est tip top... A un détail près
malheureusement...
Lorsque je suis sur la dernière ligne de mon DataSource,
Page.Details.DataSource.GetValue("imgpro" ) retourne "System.DBNull.Value".
Du coup, impossible d'afficher mon image (ici, j'affiche donc
c:\in\test.bmp).
De mémoire, j'ai déjà eu ce genre de problème avec un DataRepeater en
ASP.NET, donc plus qu'un bug de l'outil, je pense à un problème dans mon
code, genre le BeforePrint est exécuté une fois que la connexion est fermée,
ou un truc du genre.
Est-ce que d'autres personnes utilisent cette outils ? Comment faites-vous
pour afficher des images "dynamiques" ?
A défaut, quels autres outils connaissez-vous qui pourraient me permettre de
faire ça ? Je suis vraiment sur mon derrière d'être bloqué par un détail
pareil...
J'ai toujours une solution de secours (qui me ferait utiliser Crystal
Reports du coup) mais elle est tellement goret que je veux autant que
possible l'éviter. (Ecrire une PS en .NET dans mon SQL Server 2005 Express,
charger mes images à la main et les convertir en BMP, puis les injecter dans
mon DataTable avant de l'envoyer à CR... J'ai testé, ça marche, mais bon
j'ai des boutons rien que d'y penser...)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ambassadeur kosh
ben, un site web qui fabrique les pdf... pour faire du millimetré, le langage utilisé dans pdf est pil poil bien... apres, pour fabriquer le pdf en lui même, soit on crache du texte, soit on passe par une api qui offre un writer, voir des fonctionalités d'ordre superieures... NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de lignes de codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf renvoyé dans le stream du response avec un mime-type pdf, et l'affaire est faite...
non ?
ben, un site web qui fabrique les pdf...
pour faire du millimetré, le langage utilisé dans pdf est pil poil bien...
apres, pour fabriquer le pdf en lui même, soit on crache du texte, soit on
passe par une api qui offre un writer, voir des fonctionalités d'ordre
superieures...
NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de lignes de
codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf
renvoyé dans le stream du response avec un mime-type pdf, et l'affaire est
faite...
ben, un site web qui fabrique les pdf... pour faire du millimetré, le langage utilisé dans pdf est pil poil bien... apres, pour fabriquer le pdf en lui même, soit on crache du texte, soit on passe par une api qui offre un writer, voir des fonctionalités d'ordre superieures... NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de lignes de codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf renvoyé dans le stream du response avec un mime-type pdf, et l'affaire est faite...
non ?
Sylvain
Bonjour,
Merci pour cette réponse. Mais cet outils "nfop", je vois qu'il se base sur du XSL pour faire la transformation. Ok, mais ce document XSL, c'est un XSL "web" ? Parceque pour faire du millimètre près, avec comptage des pages et autres, y'a quand même mieux que du HTML...
Deplus, ce XSL, moi je dois pouvoir le créer via une GUI. Effectivement, là j'écris le programme, mais ensuite le client doit pouvoir être un minimum autonome en ce qui concerne les modifications des éditions : tant qu'il ne change pas la nature des informations, je dois le rendre capable de modifier l'aspect global de ses étiquettes lui-même, sans devoir prendre un expert en développement. Si je laisse derrière moi des XSL imbittables, je ne rempli pas trop mal part du contrat...
"Ambassadeur kosh" a écrit dans le message de news:
ben, un site web qui fabrique les pdf... pour faire du millimetré, le langage utilisé dans pdf est pil poil bien... apres, pour fabriquer le pdf en lui même, soit on crache du texte, soit on passe par une api qui offre un writer, voir des fonctionalités d'ordre superieures... NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de lignes de codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf renvoyé dans le stream du response avec un mime-type pdf, et l'affaire est faite...
non ?
Bonjour,
Merci pour cette réponse.
Mais cet outils "nfop", je vois qu'il se base sur du XSL pour faire la
transformation.
Ok, mais ce document XSL, c'est un XSL "web" ?
Parceque pour faire du millimètre près, avec comptage des pages et autres,
y'a quand même mieux que du HTML...
Deplus, ce XSL, moi je dois pouvoir le créer via une GUI.
Effectivement, là j'écris le programme, mais ensuite le client doit pouvoir
être un minimum autonome en ce qui concerne les modifications des éditions :
tant qu'il ne change pas la nature des informations, je dois le rendre
capable de modifier l'aspect global de ses étiquettes lui-même, sans devoir
prendre un expert en développement. Si je laisse derrière moi des XSL
imbittables, je ne rempli pas trop mal part du contrat...
"Ambassadeur kosh" <kosh.nospam@babylon5.fr> a écrit dans le message de
news:u8FH9ZLIIHA.1184@TK2MSFTNGP04.phx.gbl...
ben, un site web qui fabrique les pdf...
pour faire du millimetré, le langage utilisé dans pdf est pil poil bien...
apres, pour fabriquer le pdf en lui même, soit on crache du texte, soit on
passe par une api qui offre un writer, voir des fonctionalités d'ordre
superieures...
NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de lignes
de codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf
renvoyé dans le stream du response avec un mime-type pdf, et l'affaire est
faite...
Merci pour cette réponse. Mais cet outils "nfop", je vois qu'il se base sur du XSL pour faire la transformation. Ok, mais ce document XSL, c'est un XSL "web" ? Parceque pour faire du millimètre près, avec comptage des pages et autres, y'a quand même mieux que du HTML...
Deplus, ce XSL, moi je dois pouvoir le créer via une GUI. Effectivement, là j'écris le programme, mais ensuite le client doit pouvoir être un minimum autonome en ce qui concerne les modifications des éditions : tant qu'il ne change pas la nature des informations, je dois le rendre capable de modifier l'aspect global de ses étiquettes lui-même, sans devoir prendre un expert en développement. Si je laisse derrière moi des XSL imbittables, je ne rempli pas trop mal part du contrat...
"Ambassadeur kosh" a écrit dans le message de news:
ben, un site web qui fabrique les pdf... pour faire du millimetré, le langage utilisé dans pdf est pil poil bien... apres, pour fabriquer le pdf en lui même, soit on crache du texte, soit on passe par une api qui offre un writer, voir des fonctionalités d'ordre superieures... NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de lignes de codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf renvoyé dans le stream du response avec un mime-type pdf, et l'affaire est faite...
non ?
jerome crevecoeur
Payant mais ça a l'air très fonctionnel et Royaltee free http://www.devexpress.com/Products/NET/WinForms/XtraReports/
Cordialement
Ambassadeur kosh a écrit :
ben, un site web qui fabrique les pdf... pour faire du millimetré, le langage utilisé dans pdf est pil poil bien... apres, pour fabriquer le pdf en lui même, soit on crache du texte, so it on passe par une api qui offre un writer, voir des fonctionalités d'ordr e superieures... NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de l ignes de codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf renvoyé dans le stream du response avec un mime-type pdf, et l'affair e est faite...
non ?
Payant mais ça a l'air très fonctionnel et Royaltee free
http://www.devexpress.com/Products/NET/WinForms/XtraReports/
Cordialement
Ambassadeur kosh a écrit :
ben, un site web qui fabrique les pdf...
pour faire du millimetré, le langage utilisé dans pdf est pil poil bien...
apres, pour fabriquer le pdf en lui même, soit on crache du texte, so it on
passe par une api qui offre un writer, voir des fonctionalités d'ordr e
superieures...
NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de l ignes de
codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf
renvoyé dans le stream du response avec un mime-type pdf, et l'affair e est
faite...
Payant mais ça a l'air très fonctionnel et Royaltee free http://www.devexpress.com/Products/NET/WinForms/XtraReports/
Cordialement
Ambassadeur kosh a écrit :
ben, un site web qui fabrique les pdf... pour faire du millimetré, le langage utilisé dans pdf est pil poil bien... apres, pour fabriquer le pdf en lui même, soit on crache du texte, so it on passe par une api qui offre un writer, voir des fonctionalités d'ordr e superieures... NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de l ignes de codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf renvoyé dans le stream du response avec un mime-type pdf, et l'affair e est faite...
non ?
Sylvain
Merci pour ce lien. J'étais déjà tombé sur le site de cette boîte. C'est vrai qu'ils font des trucs vraiment sympas. Mais vu l'utilité de .NET dans ma boîte (je suis le seul dev qui sait en fait, et encore, en auto-didact, je passe 90% de mon temps à retourner la MSDN dans tous les sens plus qu'à coder) et un projet par ci par là quand je fais du forcing, y'a pas de quoi rentabiliser un tel investissement. Et je ne peux pas le faire payer au client, qui n'en a encore moins d'utilité... grmpf.
Par contre !
En parallèle, j'ai torturé une âme charitable sur le forum HFR, qui faute de vraiment m'aider, m'a permi de garder le peu de motivation qu'il me restait. http://forum.hardware.fr/hfr/Programmation/CNET-managed/faire-edition-papier-sujet_108233_1.htm#t1637479
J'ai donc laissé tomber MyNeoReport, retenté sans succès Crystal Reports, puis je me suis obstiné sur Microsoft Reporting Services.
Plusieurs choses : ce que je voulais faire, est finalement "relativement" facile à faire... Encore faudrait-il que Microsoft daigne écrire un minimum de documentation sur le sujet (ou la rende plus disponible, parcequ'il faut être concentré bien fort pour trouver de la doc sur cet outil), parceque c'est franchement pas intuitif !
Pour charger une image dynamiquement, dont on récupère le nom dans un champ des données en entrée, il faut... TOUT BETEMENT QUE CE CHEMIN SOIT UNE URI !!! (et mettre l'image comme "external")
c:intoto.jpg => Marche pas file:///c:/in/toto.jpg => Ca marche...
Franchement, je pense que dans la prochaine version, Microsoft peut revoir sa copie, histoire de rentre la chose un peu plus évidente. Depuis le mois de septembre, date de mes premiers tests, je n'ai jamais imaginé que si c:intoto.jpg ne marchait pas, que ça puisse marcher en tapant une uri à la place...
Enfin donc... Contrôle image avec comme "Source=External" et "Value="file:///" + (new System.Uri(Parameters!pictcache.Value + "" + Fields!imgpro.Value)).AbsolutePath"
=> Et ça marche ! (dans mon cas le paramètre "pictcache" est un répertoire local où sont stockées les images, et imgpro un champ de ma source de données qui contient le nom de l'image uniquement).
"jerome crevecoeur" a écrit dans le message de news: Payant mais ça a l'air très fonctionnel et Royaltee free http://www.devexpress.com/Products/NET/WinForms/XtraReports/
Cordialement
Ambassadeur kosh a écrit :
ben, un site web qui fabrique les pdf... pour faire du millimetré, le langage utilisé dans pdf est pil poil bien... apres, pour fabriquer le pdf en lui même, soit on crache du texte, soit on passe par une api qui offre un writer, voir des fonctionalités d'ordre superieures... NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de lignes de codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf renvoyé dans le stream du response avec un mime-type pdf, et l'affaire est faite...
non ?
Merci pour ce lien.
J'étais déjà tombé sur le site de cette boîte. C'est vrai qu'ils font des
trucs vraiment sympas.
Mais vu l'utilité de .NET dans ma boîte (je suis le seul dev qui sait en
fait, et encore, en auto-didact, je passe 90% de mon temps à retourner la
MSDN dans tous les sens plus qu'à coder) et un projet par ci par là quand je
fais du forcing, y'a pas de quoi rentabiliser un tel investissement.
Et je ne peux pas le faire payer au client, qui n'en a encore moins
d'utilité... grmpf.
Par contre !
En parallèle, j'ai torturé une âme charitable sur le forum HFR, qui faute de
vraiment m'aider, m'a permi de garder le peu de motivation qu'il me restait.
http://forum.hardware.fr/hfr/Programmation/CNET-managed/faire-edition-papier-sujet_108233_1.htm#t1637479
J'ai donc laissé tomber MyNeoReport, retenté sans succès Crystal Reports,
puis je me suis obstiné sur Microsoft Reporting Services.
Plusieurs choses : ce que je voulais faire, est finalement "relativement"
facile à faire... Encore faudrait-il que Microsoft daigne écrire un minimum
de documentation sur le sujet (ou la rende plus disponible, parcequ'il faut
être concentré bien fort pour trouver de la doc sur cet outil), parceque
c'est franchement pas intuitif !
Pour charger une image dynamiquement, dont on récupère le nom dans un champ
des données en entrée, il faut... TOUT BETEMENT QUE CE CHEMIN SOIT UNE URI
!!! (et mettre l'image comme "external")
c:intoto.jpg => Marche pas
file:///c:/in/toto.jpg => Ca marche...
Franchement, je pense que dans la prochaine version, Microsoft peut revoir
sa copie, histoire de rentre la chose un peu plus évidente. Depuis le mois
de septembre, date de mes premiers tests, je n'ai jamais imaginé que si
c:intoto.jpg ne marchait pas, que ça puisse marcher en tapant une uri à la
place...
Enfin donc...
Contrôle image avec comme "Source=External" et "Value="file:///" + (new
System.Uri(Parameters!pictcache.Value + "" +
Fields!imgpro.Value)).AbsolutePath"
=> Et ça marche ! (dans mon cas le paramètre "pictcache" est un répertoire
local où sont stockées les images, et imgpro un champ de ma source de
données qui contient le nom de l'image uniquement).
"jerome crevecoeur" <spamailleurs.crevecoeur.spamailleurs.jerome@wanadoo.fr>
a écrit dans le message de news:uMrjF1RIIHA.1168@TK2MSFTNGP02.phx.gbl...
Payant mais ça a l'air très fonctionnel et Royaltee free
http://www.devexpress.com/Products/NET/WinForms/XtraReports/
Cordialement
Ambassadeur kosh a écrit :
ben, un site web qui fabrique les pdf...
pour faire du millimetré, le langage utilisé dans pdf est pil poil bien...
apres, pour fabriquer le pdf en lui même, soit on crache du texte, soit on
passe par une api qui offre un writer, voir des fonctionalités d'ordre
superieures...
NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de lignes
de codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf
renvoyé dans le stream du response avec un mime-type pdf, et l'affaire est
faite...
Merci pour ce lien. J'étais déjà tombé sur le site de cette boîte. C'est vrai qu'ils font des trucs vraiment sympas. Mais vu l'utilité de .NET dans ma boîte (je suis le seul dev qui sait en fait, et encore, en auto-didact, je passe 90% de mon temps à retourner la MSDN dans tous les sens plus qu'à coder) et un projet par ci par là quand je fais du forcing, y'a pas de quoi rentabiliser un tel investissement. Et je ne peux pas le faire payer au client, qui n'en a encore moins d'utilité... grmpf.
Par contre !
En parallèle, j'ai torturé une âme charitable sur le forum HFR, qui faute de vraiment m'aider, m'a permi de garder le peu de motivation qu'il me restait. http://forum.hardware.fr/hfr/Programmation/CNET-managed/faire-edition-papier-sujet_108233_1.htm#t1637479
J'ai donc laissé tomber MyNeoReport, retenté sans succès Crystal Reports, puis je me suis obstiné sur Microsoft Reporting Services.
Plusieurs choses : ce que je voulais faire, est finalement "relativement" facile à faire... Encore faudrait-il que Microsoft daigne écrire un minimum de documentation sur le sujet (ou la rende plus disponible, parcequ'il faut être concentré bien fort pour trouver de la doc sur cet outil), parceque c'est franchement pas intuitif !
Pour charger une image dynamiquement, dont on récupère le nom dans un champ des données en entrée, il faut... TOUT BETEMENT QUE CE CHEMIN SOIT UNE URI !!! (et mettre l'image comme "external")
c:intoto.jpg => Marche pas file:///c:/in/toto.jpg => Ca marche...
Franchement, je pense que dans la prochaine version, Microsoft peut revoir sa copie, histoire de rentre la chose un peu plus évidente. Depuis le mois de septembre, date de mes premiers tests, je n'ai jamais imaginé que si c:intoto.jpg ne marchait pas, que ça puisse marcher en tapant une uri à la place...
Enfin donc... Contrôle image avec comme "Source=External" et "Value="file:///" + (new System.Uri(Parameters!pictcache.Value + "" + Fields!imgpro.Value)).AbsolutePath"
=> Et ça marche ! (dans mon cas le paramètre "pictcache" est un répertoire local où sont stockées les images, et imgpro un champ de ma source de données qui contient le nom de l'image uniquement).
"jerome crevecoeur" a écrit dans le message de news: Payant mais ça a l'air très fonctionnel et Royaltee free http://www.devexpress.com/Products/NET/WinForms/XtraReports/
Cordialement
Ambassadeur kosh a écrit :
ben, un site web qui fabrique les pdf... pour faire du millimetré, le langage utilisé dans pdf est pil poil bien... apres, pour fabriquer le pdf en lui même, soit on crache du texte, soit on passe par une api qui offre un writer, voir des fonctionalités d'ordre superieures... NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de lignes de codes, vous devriez arriver à faire quelque chose de pas mal...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, un pdf renvoyé dans le stream du response avec un mime-type pdf, et l'affaire est faite...
non ?
jerome crevecoeur
Merci de ce retour Sylvain. Il est vrai qu'en .NEt, il faut vraiment marcher dans les clous et bien faire attention au Type/Objet attendu.
Cordialement
Sylvain a écrit :
Merci pour ce lien. J'étais déjà tombé sur le site de cette boîte. C'est vrai qu' ils font des trucs vraiment sympas. Mais vu l'utilité de .NET dans ma boîte (je suis le seul dev qui sa it en fait, et encore, en auto-didact, je passe 90% de mon temps à retourne r la MSDN dans tous les sens plus qu'à coder) et un projet par ci par l à quand je fais du forcing, y'a pas de quoi rentabiliser un tel investissement. Et je ne peux pas le faire payer au client, qui n'en a encore moins d'utilité... grmpf.
Par contre !
En parallèle, j'ai torturé une âme charitable sur le forum HFR, q ui faute de vraiment m'aider, m'a permi de garder le peu de motivation qu'il me restait. http://forum.hardware.fr/hfr/Programmation/CNET-managed/faire-edition-p apier-sujet_108233_1.htm#t1637479
J'ai donc laissé tomber MyNeoReport, retenté sans succès Crystal Reports, puis je me suis obstiné sur Microsoft Reporting Services.
Plusieurs choses : ce que je voulais faire, est finalement "relativement" facile à faire... Encore faudrait-il que Microsoft dai gne écrire un minimum de documentation sur le sujet (ou la rende plus disponible, parcequ'il faut être concentré bien fort pour trouver d e la doc sur cet outil), parceque c'est franchement pas intuitif !
Pour charger une image dynamiquement, dont on récupère le nom dans un champ des données en entrée, il faut... TOUT BETEMENT QUE CE CHEMIN SOIT UNE URI !!! (et mettre l'image comme "external")
c:intoto.jpg => Marche pas file:///c:/in/toto.jpg => Ca marche...
Franchement, je pense que dans la prochaine version, Microsoft peut revoir sa copie, histoire de rentre la chose un peu plus évidente. Depuis le mois de septembre, date de mes premiers tests, je n'ai jamais imaginé que si c:intoto.jpg ne marchait pas, que ça puisse marche r en tapant une uri à la place...
Enfin donc... Contrôle image avec comme "Source=External" et "Value="file:///" + (new System.Uri(Parameters!pictcache.Value + "" + Fields!imgpro.Value)).AbsolutePath"
=> Et ça marche ! (dans mon cas le paramètre "pictcache" est un répertoire local où sont stockées les images, et imgpro un champ de ma source de données qui contient le nom de l'image uniquement).
"jerome crevecoeur" a écrit dans le message de news: Payant mais ça a l'air très fonctionnel et Royaltee free http://www.devexpress.com/Products/NET/WinForms/XtraReports/
Cordialement
Ambassadeur kosh a écrit :
ben, un site web qui fabrique les pdf... pour faire du millimetré, le langage utilisé dans pdf est pil poil bien... apres, pour fabriquer le pdf en lui même, soit on crache du texte, soit on passe par une api qui offre un writer, voir des fonctionalité s d'ordre superieures... NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de lignes de codes, vous devriez arriver à faire quelque chose de pas m al...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, u n pdf renvoyé dans le stream du response avec un mime-type pdf, et l'affaire est faite...
non ?
Merci de ce retour Sylvain.
Il est vrai qu'en .NEt, il faut vraiment marcher dans les clous et bien
faire attention au Type/Objet attendu.
Cordialement
Sylvain a écrit :
Merci pour ce lien.
J'étais déjà tombé sur le site de cette boîte. C'est vrai qu' ils font
des trucs vraiment sympas.
Mais vu l'utilité de .NET dans ma boîte (je suis le seul dev qui sa it en
fait, et encore, en auto-didact, je passe 90% de mon temps à retourne r
la MSDN dans tous les sens plus qu'à coder) et un projet par ci par l à
quand je fais du forcing, y'a pas de quoi rentabiliser un tel
investissement.
Et je ne peux pas le faire payer au client, qui n'en a encore moins
d'utilité... grmpf.
Par contre !
En parallèle, j'ai torturé une âme charitable sur le forum HFR, q ui
faute de vraiment m'aider, m'a permi de garder le peu de motivation
qu'il me restait.
http://forum.hardware.fr/hfr/Programmation/CNET-managed/faire-edition-p apier-sujet_108233_1.htm#t1637479
J'ai donc laissé tomber MyNeoReport, retenté sans succès Crystal
Reports, puis je me suis obstiné sur Microsoft Reporting Services.
Plusieurs choses : ce que je voulais faire, est finalement
"relativement" facile à faire... Encore faudrait-il que Microsoft dai gne
écrire un minimum de documentation sur le sujet (ou la rende plus
disponible, parcequ'il faut être concentré bien fort pour trouver d e la
doc sur cet outil), parceque c'est franchement pas intuitif !
Pour charger une image dynamiquement, dont on récupère le nom dans un
champ des données en entrée, il faut... TOUT BETEMENT QUE CE CHEMIN SOIT
UNE URI !!! (et mettre l'image comme "external")
c:intoto.jpg => Marche pas
file:///c:/in/toto.jpg => Ca marche...
Franchement, je pense que dans la prochaine version, Microsoft peut
revoir sa copie, histoire de rentre la chose un peu plus évidente.
Depuis le mois de septembre, date de mes premiers tests, je n'ai jamais
imaginé que si c:intoto.jpg ne marchait pas, que ça puisse marche r en
tapant une uri à la place...
Enfin donc...
Contrôle image avec comme "Source=External" et "Value="file:///" + (new
System.Uri(Parameters!pictcache.Value + "" +
Fields!imgpro.Value)).AbsolutePath"
=> Et ça marche ! (dans mon cas le paramètre "pictcache" est un
répertoire local où sont stockées les images, et imgpro un champ de ma
source de données qui contient le nom de l'image uniquement).
"jerome crevecoeur"
<spamailleurs.crevecoeur.spamailleurs.jerome@wanadoo.fr> a écrit dans le
message de news:uMrjF1RIIHA.1168@TK2MSFTNGP02.phx.gbl...
Payant mais ça a l'air très fonctionnel et Royaltee free
http://www.devexpress.com/Products/NET/WinForms/XtraReports/
Cordialement
Ambassadeur kosh a écrit :
ben, un site web qui fabrique les pdf...
pour faire du millimetré, le langage utilisé dans pdf est pil poil
bien...
apres, pour fabriquer le pdf en lui même, soit on crache du texte,
soit on passe par une api qui offre un writer, voir des fonctionalité s
d'ordre superieures...
NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de
lignes de codes, vous devriez arriver à faire quelque chose de pas m al...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, u n
pdf renvoyé dans le stream du response avec un mime-type pdf, et
l'affaire est faite...
Merci de ce retour Sylvain. Il est vrai qu'en .NEt, il faut vraiment marcher dans les clous et bien faire attention au Type/Objet attendu.
Cordialement
Sylvain a écrit :
Merci pour ce lien. J'étais déjà tombé sur le site de cette boîte. C'est vrai qu' ils font des trucs vraiment sympas. Mais vu l'utilité de .NET dans ma boîte (je suis le seul dev qui sa it en fait, et encore, en auto-didact, je passe 90% de mon temps à retourne r la MSDN dans tous les sens plus qu'à coder) et un projet par ci par l à quand je fais du forcing, y'a pas de quoi rentabiliser un tel investissement. Et je ne peux pas le faire payer au client, qui n'en a encore moins d'utilité... grmpf.
Par contre !
En parallèle, j'ai torturé une âme charitable sur le forum HFR, q ui faute de vraiment m'aider, m'a permi de garder le peu de motivation qu'il me restait. http://forum.hardware.fr/hfr/Programmation/CNET-managed/faire-edition-p apier-sujet_108233_1.htm#t1637479
J'ai donc laissé tomber MyNeoReport, retenté sans succès Crystal Reports, puis je me suis obstiné sur Microsoft Reporting Services.
Plusieurs choses : ce que je voulais faire, est finalement "relativement" facile à faire... Encore faudrait-il que Microsoft dai gne écrire un minimum de documentation sur le sujet (ou la rende plus disponible, parcequ'il faut être concentré bien fort pour trouver d e la doc sur cet outil), parceque c'est franchement pas intuitif !
Pour charger une image dynamiquement, dont on récupère le nom dans un champ des données en entrée, il faut... TOUT BETEMENT QUE CE CHEMIN SOIT UNE URI !!! (et mettre l'image comme "external")
c:intoto.jpg => Marche pas file:///c:/in/toto.jpg => Ca marche...
Franchement, je pense que dans la prochaine version, Microsoft peut revoir sa copie, histoire de rentre la chose un peu plus évidente. Depuis le mois de septembre, date de mes premiers tests, je n'ai jamais imaginé que si c:intoto.jpg ne marchait pas, que ça puisse marche r en tapant une uri à la place...
Enfin donc... Contrôle image avec comme "Source=External" et "Value="file:///" + (new System.Uri(Parameters!pictcache.Value + "" + Fields!imgpro.Value)).AbsolutePath"
=> Et ça marche ! (dans mon cas le paramètre "pictcache" est un répertoire local où sont stockées les images, et imgpro un champ de ma source de données qui contient le nom de l'image uniquement).
"jerome crevecoeur" a écrit dans le message de news: Payant mais ça a l'air très fonctionnel et Royaltee free http://www.devexpress.com/Products/NET/WinForms/XtraReports/
Cordialement
Ambassadeur kosh a écrit :
ben, un site web qui fabrique les pdf... pour faire du millimetré, le langage utilisé dans pdf est pil poil bien... apres, pour fabriquer le pdf en lui même, soit on crache du texte, soit on passe par une api qui offre un writer, voir des fonctionalité s d'ordre superieures... NFop pourrait faire l'affaire à bien regarder...
quand à l'alimentation des report avec des données, ben en peu de lignes de codes, vous devriez arriver à faire quelque chose de pas m al...
donc, pas d'outils payants et lourdingues, des apis pas méchantes, u n pdf renvoyé dans le stream du response avec un mime-type pdf, et l'affaire est faite...
non ?
Ambassadeur kosh
"Sylvain" a écrit dans le message de news:
Bonjour,
Merci pour cette réponse. Mais cet outils "nfop", je vois qu'il se base sur du XSL pour faire la transformation. Ok, mais ce document XSL, c'est un XSL "web" ? Parceque pour faire du millimètre près, avec comptage des pages et autres, y'a quand même mieux que du HTML...
mais non, xsl, ça genere du texte. point final. ce texe, ça peut etre du html, du xml, du texte à plat, mais aussi du pdf, etc etc... nfop, c'est un outils qui s'appuie sur un schema comme mathml ou cml, mais pour faire de la présentation. en gros c'est le pdf "en clair" et en structuré. et 'ailleurs, ça produit du pdf.
Deplus, ce XSL, moi je dois pouvoir le créer via une GUI. Effectivement, là j'écris le programme, mais ensuite le client doit pouvoir être un minimum autonome en ce qui concerne les modifications des éditions : tant qu'il ne change pas la nature des informations, je dois le rendre capable de modifier l'aspect global de ses étiquettes lui-même, sans devoir prendre un expert en développement. Si je laisse derrière moi des XSL imbittables, je ne rempli pas trop mal part du contrat...
y'aura un peu de travail pour faire un éditeur, mais globallement, si c'est des etiquettes, ça doit pas etre bien compliqué à modeliser. je me demande meme dans quelle limite vous n'auriez pas interet à faire votre impression avec un Graphics directement...
"Sylvain" <administrateur@manga-torii.com> a écrit dans le message de news:
89829AC0-D555-4BC5-B7E8-529F9670E7EE@microsoft.com...
Bonjour,
Merci pour cette réponse.
Mais cet outils "nfop", je vois qu'il se base sur du XSL pour faire la
transformation.
Ok, mais ce document XSL, c'est un XSL "web" ?
Parceque pour faire du millimètre près, avec comptage des pages et autres,
y'a quand même mieux que du HTML...
mais non, xsl, ça genere du texte. point final.
ce texe, ça peut etre du html, du xml, du texte à plat, mais aussi du pdf,
etc etc...
nfop, c'est un outils qui s'appuie sur un schema comme mathml ou cml, mais
pour faire de la présentation. en gros c'est le pdf "en clair" et en
structuré. et 'ailleurs, ça produit du pdf.
Deplus, ce XSL, moi je dois pouvoir le créer via une GUI.
Effectivement, là j'écris le programme, mais ensuite le client doit
pouvoir être un minimum autonome en ce qui concerne les modifications des
éditions : tant qu'il ne change pas la nature des informations, je dois le
rendre capable de modifier l'aspect global de ses étiquettes lui-même,
sans devoir prendre un expert en développement. Si je laisse derrière moi
des XSL imbittables, je ne rempli pas trop mal part du contrat...
y'aura un peu de travail pour faire un éditeur, mais globallement, si c'est
des etiquettes, ça doit pas etre bien compliqué à modeliser. je me demande
meme dans quelle limite vous n'auriez pas interet à faire votre impression
avec un Graphics directement...
Merci pour cette réponse. Mais cet outils "nfop", je vois qu'il se base sur du XSL pour faire la transformation. Ok, mais ce document XSL, c'est un XSL "web" ? Parceque pour faire du millimètre près, avec comptage des pages et autres, y'a quand même mieux que du HTML...
mais non, xsl, ça genere du texte. point final. ce texe, ça peut etre du html, du xml, du texte à plat, mais aussi du pdf, etc etc... nfop, c'est un outils qui s'appuie sur un schema comme mathml ou cml, mais pour faire de la présentation. en gros c'est le pdf "en clair" et en structuré. et 'ailleurs, ça produit du pdf.
Deplus, ce XSL, moi je dois pouvoir le créer via une GUI. Effectivement, là j'écris le programme, mais ensuite le client doit pouvoir être un minimum autonome en ce qui concerne les modifications des éditions : tant qu'il ne change pas la nature des informations, je dois le rendre capable de modifier l'aspect global de ses étiquettes lui-même, sans devoir prendre un expert en développement. Si je laisse derrière moi des XSL imbittables, je ne rempli pas trop mal part du contrat...
y'aura un peu de travail pour faire un éditeur, mais globallement, si c'est des etiquettes, ça doit pas etre bien compliqué à modeliser. je me demande meme dans quelle limite vous n'auriez pas interet à faire votre impression avec un Graphics directement...
Sylfelin
Ca ne fait aps tout ce que tu veux mais il y a aussi : http://itextsharp.sourceforge.net/ et http://itextsharp.sourceforge.net/tutorial/index.html
--
-------------------------- Merci Sylfelin
Ca ne fait aps tout ce que tu veux mais il y a aussi :
http://itextsharp.sourceforge.net/
et
http://itextsharp.sourceforge.net/tutorial/index.html
Ca ne fait aps tout ce que tu veux mais il y a aussi : http://itextsharp.sourceforge.net/ et http://itextsharp.sourceforge.net/tutorial/index.html
--
-------------------------- Merci Sylfelin
OD
je te conseille de regarder du côté de RDL, c'est gratuit, c'est Microsoft, et ça permet facilement de faire des PDF. La liaison aux données est simple et efficace, même avec des grappes en mémoire.
j'ai écrit un article là dessus, voici l'entrée de mon blog qui donne les détails : http://e-naxos.com/Blog/post.aspx?idÜ4fca81-7e3e-4903-8aca-9f6480e21090
--
Olivi3r_____
Dot.Blog - C# LINQ VS ... www.e-naxos.com/blog
je te conseille de regarder du côté de RDL, c'est gratuit, c'est
Microsoft, et ça permet facilement de faire des PDF. La liaison aux
données est simple et efficace, même avec des grappes en mémoire.
j'ai écrit un article là dessus, voici l'entrée de mon blog qui donne
les détails :
http://e-naxos.com/Blog/post.aspx?idÜ4fca81-7e3e-4903-8aca-9f6480e21090
je te conseille de regarder du côté de RDL, c'est gratuit, c'est Microsoft, et ça permet facilement de faire des PDF. La liaison aux données est simple et efficace, même avec des grappes en mémoire.
j'ai écrit un article là dessus, voici l'entrée de mon blog qui donne les détails : http://e-naxos.com/Blog/post.aspx?idÜ4fca81-7e3e-4903-8aca-9f6480e21090
