Bogue interface C++ Builder 6 TQuickReport

Bonjour

je découvre un bogue dans l'EDI. Si on crée une fiche Etat (TQuickReport) l'EDI comme d'habitude génère .CPP .h .DFM avec les déclarations par défaut.

Le composant TQuickReport s'appelle TQuickReport1 et généralement on éprouve le besoin de le renommer. Théoriquement toutes les variables sont renommées. Dans le cas de C++ Builder 6 l’une d'elle est "oubliée" c'est la seconde mention du nom de l'instanciation dans le prototype (.H) du constructeur.

Initialement on a

Code:

---

__fastcall TFQuickReport1::TFQuickReport1(TComponent* Owner);

---

qui si l'on renomme la fiche 'QR' devrait devenir

Code:

---

__fastcall TQR::TQR(TComponent* Owner);

---

et qui devient en réalité

Code:

---

__fastcall TQR::TFQuickReport1(TComponent* Owner);

---

la compilation ne retrouve donc pas le constructeur

Bonjour,

Lorsque j'ai eu à utiliser QuickReport (sous BCB5), j'ai toujours privilégié la solution de poser un composant TQuickRep (onglet QReport) sur un TForm et je n'ai jamais eu de soucis.

Il me semble avoir eu (il y a très très longtemps) également des soucis de ce genre en utilisant directement un composant TQuickReport (via Fichier->Nouveau->Etat).

Essai d'utiliser la solution de poser un TQuickRep sur une fiche (TForm) à part. Perso je n'ai jamais rencontré de soucis avec ce composant en l'utilisant comme ça.

Mais pour ton problème en particulier, renommer correctement le constructeur dans le *.h devrait résoudre ton problème.

En même temps, évoquer un bug de la version 6 alors qu'il existe la version 18 (XE4)
Borland a remplacé QR par RaveReport dans Delphi 7, c'est peut-être parce que QR n'était plus adéquat avec l'efficience que souhaitait Borland à l'époque
Embarcadero semble maintenant préféré FastReport !

Je me souviens pas du tout du TQuickReport
J'ai un vague souvenir du TQuickRep !

Un de mes collègues passait par un héritage direct d'un TQuickRep
Je pense c'est ce que tu as fais en héritant de TQuickReport

Comme sat83, je préfèrait un TForm dans lequel on déposait un TQuickRep
Même Quickreport le conseille aussi : TQuickRep Component :

Citation:

---

But we recommend, from experience, that you put a TQuickRep component on a form: it’s the more versatile approach.

---

Hello,

Tiens, un bug dans Builder 6 ?
Tu verras, ce n'est pas le seul !
Exemple, toujours dans la série "on renomme la fiche, et paf", si tu ajoutes un destructeur à ta fiche, et que tu la renommes, l'IDE ne fera qu'un tiers du boulot pour renommer le destructeur....
Il suffit de corriger les crasses laissées par l'IDE...

Pour Shai:

Citation:

---

Dans ton exemple ce n'est pas le composant TQuickReport ou TQuickRep mais la TForm qui contient l'objet QR !

---

Techniquement, dans son exemple, il n'a pas posé de composant sur sa fiche, mais il a fait dériver directement sa fiche de TQuickRep... On en revient donc aux petits désagréments liés au renommage de fiches dans l'IDE de Builder 6...
Edit: OK Shai, même plus le temps de répondre que déjà tu as édité ton post !

Citation:

---

Envoyé par totoche76

Edit: OK Shai, même plus le temps de répondre que déjà tu as édité ton post !

---

Oui, le temps que je regarde des vieux codes de 2002 utilisant un TQuickRep, j'ai vu alors la double utilisation
soit par héritage d'un TQuickRep (ça je m'en souvenais pas du tout)
soit par composition d'un TQuickRep dans une TForm

Le bug de renommage est probablement lié à l'héritage du TQuickReport

Je n'ai jamais bossé sur BCB6 (juste par curiosité pour le comparer au 2007)
C'est comme le coup du #ifndef Unit1H qui doit être dans la bonne casse pour que l'IDE regroupe le CPP et le H ensemble dans l'éditeur,
c'était le cas en 2007, et toujours en XE3, je pense, en corrigeant quelques ifndef en début de H, j'ai pu corriger des erreurs de regroupement de fichier dans le projet que je maintiens

Bon, il y a toujours quelques brouilles sur la recherche qui s'on ouvre le H seul via un double-clic sur un élément trouvé dans le H
puis si l'on double-clic sur un autre élément trouvé dans le CPP
il ré-ouvre le CPP+H et si l'on modifie les deux H sans faire gaffe : patatra perte de code !

Citation:

---

Envoyé par ShaiLeTroll

Borland a remplacé QR par RaveReport dans Delphi 7, c'est peut-être parce que QR n'était plus adéquat avec l'efficience que souhaitait Borland à l'époque
Embarcadero semble maintenant préféré FastReport !

Je me souviens pas du tout du TQuickReport
J'ai un vague souvenir du TQuickRep !
Même Quickreport le conseille aussi : TQuickRep Component :

---

Oui en effet dans l'application que je continue de faire évoluer existe ces deux cas de figure TQuickReport posé un TForm et TQuickReport direct.

Cela dit le problème évoqué n'est évidemment pas insurmontable et j'ai juste voulu partager le cas.

Concernant QuickReport/Rave c'est bien le problème. Quand on doit faire évoluer une application qui contient des dizaines d'état on réfléchit un peu avant de tout recoder en Rave et on a raison puisque ce composant cède maintenant le pas à un autre.

Quand à migrer vers une version plus récente (CodeGear 2009) ce fut un fiasco total pour plusieurs raisons dont certaines sont bien connues de ce forum.

Enfin l'achat des toutes dernières licences est repoussée pour le moment car c'est un investissement conséquent. Donc on fait vivre C++ Builder en se disant que c'est dans les vieux pots ... Mais bien sûr cela n'aura qu'un temps !