Discussion :

[Flode]

Bonjour,

Malgré la lecture de la FAQs et les messages dénichés dans le forum (cf. échantillon ci-dessous), je n'ai pas réussi trouver ce qu'il fallait faire concrètement pour pouvoir appeler des états Crystal report depuis Delphi.

http://www.developpez.net/forums/d14...report-2008-a/
http://www.developpez.net/forums/d13...rt-crpe32-dll/


Je crois comprendre qu'il n'y a plus qu'un accès possible via ".Net" ou un "Wrapper", mais je sèche pour les mettre en oeuvre

Est-ce que quelqu'un utiliserait cette combinaison D7-CR2008... et pourrait me décrire la démarche de déploiement ?

merci d'avance,

[ShaiLeTroll]

Si tu trouves une autre solution, entre temps, pense à la signaler, j'ai changé de société et je ne travaille puis sur CR
Voici ce que j'ai vu à l'époque

Installe Visual Studio Express
Installe CR2008
Import le composant Report dans une nouvelle Assembly C# et active l'interopérabilité COM
Ajoute les méthodes et propriétés qui te seront nécessaire dans cette Assembly (les méthodes comme PrintToPrinter, la liste des tables et des SQL présents dans le Report : voir CrystalDecisions.CrystalReports.EngineReportDocument et DataDefinition )
Enregistre l'Assembly
Import l'objet compatible COM dans Delphi (je l'ai expérimenté en BCB2007 et BCBXE3 mais le COM en Delphi 7 fonctionnera aussi)
Et utilise ta propre Assembly pour piloter CR2008

Dans cette configuration, tu ne pourras plus envoyé de DataSet Delphi dans CR, il te faudra lui envoyer le SQL, c'est CR qui l'exécutera
Modifier le SQL, tu verras, ce n'est pas le plus évident, mon responsable de l'époque avait pondu ce Wrapper en 2-3 jours, j'avais fait une petite modification pour gérer les SQL des sous-rapports mais disons qu'au bout de 2 semaines,
le wrapper était complet pour l'utilisation que l'on en faisait et les deux versions de CR cohabitait dans l'application :
le code BCB contenait les deux versions de CR,
- la CR8 en VCL invoqué en direct pour les rapports non migrés
- la CR12 (2008) pour les rapports migrés !
Le module de rapport avait une structure objet pas trop mal construite ce qui a permis de gérer via polymorphisme le passage de l'un à l'autre

Pense que la passage de CR8 à CR12, c'est du travail, certains rapports ont presque été refait !
Créer le Wrapper, ce n'est rien mais juste le début de vrai travail !
Je pense qu'il a fallu 150jrs/homme pour migrer une centaine de rapport pour changer le code d'appel et aussi pour changer le report en lui (en particulier sa construction SQL) et retoucher le Design

[Flode]

Bonjour,

Merci pour cette réponse et désolé pour ce long silence.

Au vu des étapes à franchir, je crois que j'aurais plus vite fait de refaire les quelques états nécessaire dans Quick report.

Merci encore

[SergioMaster]

Au vu des étapes à franchir, je crois que j'aurais plus vite fait de refaire les quelques états nécessaires dans Quickreport.

Quickreport, pas sûr que ce soit le meilleur choix. Tout dépend de l'évolution après, avec D7 est arrivé RaveReport qui est laissé pour compte depuis les nouvelles versions XE au profit de FastReport (existant déjà pour D7)

Avantages des uns et des autres :
- Quickreport , état inclus dans le programme
- RaveReport , ensemble des états indépendant du programme (un fichier pour tous les états)
- FastReport , un fichier indépendant par état

Inconvénients
- Quickreport , état inclus dans le programme
- RaveReport , manuels et supports quasi inexistant, vision un peu différente de la construction d'un état (par région), Scripts internes à éviter (AMHA)
- FastReport , bien vérifier que les évènements sont gérés par la version, IHM un peu surprenant

en Conclusion : Fastreport semble un peu un mix de Quickreport et Rave, des outils de migration sont possible de quick et rave vers Fastreport mais je dois avouer que mes essais n'ont pas été très concluants