Discussion :

[ShaiLeTroll]

C'est un héritage manuel, sans passer par Delphi (pas de DFM en inherited)

J'ai dans l'application que je maintiens, ce code (simplifié et censuré), je précise, c'est un Form SANS DFM dans une simple unit, comme si je déclarais une classe quelconque ... c'est vrai, j'aurais pu faire deux objets, la fenêtre (vue) et un controleur (via implementation d'interface au lieu de virtual abstract), mais bon ...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
  TSaisieForm = class(TForm)
  published
    lblPatientInfo: TLabel;
  protected
    FIdentifiant: string;
    function GetPatientInfo: string;
  public
    constructor Create(const AIdentifiant: string); reintroduce;
 
    function GetValue(const ValueName: string): Variant; virtual; abstract;
    class function CanShow(): Boolean; virtual; abstract;
  end;
  TSaisieFormClass = class of TSaisieForm ;

Derrière j'ai une Factory qui en fonction de paramètre va me créer une Form Héritée (celle-ci ont chacune une DFM), le type de classe est déterminée à l'execution ...

J'ai du bidouillé en vitesse, ce matin, un affichage, comme je ne voulais pas dupliquer le code d'affichage (remplissage d'un label tout le temps le même), j'ai donc déclaré ce lblPatientInfo alors qu'il n'y a pas de DFM dans la classe de base.
Puis dans les classes héritées, j'ai mis le lblPatientInfo dans la DFM mais je l'ai retiré du code puisque déjà présent dans l'ancêtre ... bon vous voyez ...

Je voudrais savoir ce que vous en pensez ... et les risques ...

[Andnotor]

Je pense que tu risques surtout d'énerver les gens qui devront reprendre ce projet après toi

[philnext]

..C'est quoi le but ? Hériter des Forms pour éviter de trimballer plein de fois les même trucs dans le code ?

[ShaiLeTroll]

@Andnotor, j'ai commenté ma bizarrie, mais je te confirme c'est pas sympa pour les suivants, mais j'en ai laissé d'autre pas mal dans le genre comme avec Pointer de Procédure ... mais je peux te dire que mes prédecesseurs m'ont laissé du coup bien pourri, si tu voyais les merdes que je dois maintenir ... et encore, j'ai fait des codes bien plus délirant avec les RTTI, mais je n'avais encore jamais déclarer un membre dans l'ancêtre qui est dans les DFM des classes héritées ... quoi-que dans une autre application ... si maintenant que j'y pense une application que je mantiens génère des DFM à partir de XML et XSL, et comme cela utilise une classe spécifique de Form, lors du chargement dynamique de la DFM, cela gère les références publiées contenus dans la Classe ... finalement, je ne suis pas le seul à avoir des idées tordues ...

Dans le genre bizarre, un système qui utilisant le nom du control (comme TEdit) pour déterminer le champ et thésaurus à lire\écrire dans la DB pour un modèle d'objet persistant (comme Bold ou InstantObject) ... eh bien comme il y avait plusieurs fois le même controle pour affiche à différents endroits la même valeur (avec un nom différent du moins genre ed_NomChamp_NomDico_1, ed_NomChamp_NomDico_2, ed_NomChamp_NomDico_3 ...) et bien sur à l'écriture ça foutait le bordel ... puisque si l'on modifiait le 1 ou 2, le 3ème remettait une autre valeur, va déboguer ce genre de chose ... ah la propriété Modified du TEdit ne fonctionnait plus, c'était un compo maison bien pourri ...




@philnext, c'est ça, uniquement bénéficier des fondamentaux de la programmation objet en évitant de dupliquer du code inutilement dans 10 unités ...

[Franck SORIANO]

J'ai du bidouillé en vitesse, ce matin, un affichage, comme je ne voulais pas dupliquer le code d'affichage (remplissage d'un label tout le temps le même), j'ai donc déclaré ce lblPatientInfo alors qu'il n'y a pas de DFM dans la classe de base.
Puis dans les classes héritées, j'ai mis le lblPatientInfo dans la DFM mais je l'ai retiré du code puisque déjà présent dans l'ancêtre ... bon vous voyez ...

Personnellement, c'est bien la seule chose qui me semble suspecte.
Si tu veux être certain de ne pas avoir de problème (mis à part que l'héritage de form et l'IDE, c'est une source de problèmes), il serait quand même préférable soit de mettre un DFM pour la form de base (afin qu'ensuite les forms dérivées puissent afficher le label de l'ancêtre), soit créer le label entièrement dynamiquement. Mais dans ce dernier cas, les fiches dérivées n'afficheront pas le label en design.

PS: Ton nouveau constructeur Create ne devrait-il pas être virtuel ?

[ShaiLeTroll]

le reintroduce, j'avoue c'est un truc un peu bizarre, mais en fait cela fonctionne sans soucis ... même sens le virtual, cela fonctionne parce que je ne surcharge pas le constructeur dans les fenêtres héritées, mais dans le principe, c'est mieux de l'ajouter, cela m'évitera de m'arracher les cheveux si un jour je surcharge le constructeur ... bien vu !

Pour la DFM dans l'ancêtre, j'aurais pu, mais ça me gave, ça me fout des DFM en inherited, et j'ai eu de mauvaises expériences avec ça !

Pour l'instanciation dynamique ne poserait pas de problème (l'emplacement étant alTop), c'est aussi une très bonne idée !!!

[Kaféine]

Salut,

j'ai donc déclaré ce lblPatientInfo alors qu'il n'y a pas de DFM dans la classe de base.
Puis dans les classes héritées, j'ai mis le lblPatientInfo dans la DFM mais je l'ai retiré du code puisque déjà présent dans l'ancêtre ... bon vous voyez ...

du coup tu perd l'intérêt de l'héritage puisque si je comprend bien, tu colles le label dans chacune des forms héritées? Si tu avais une form de base, suffisait de coller le label sur cette form de base, et la repercuter sur les descendants?

Les extravagances delphi de ShaiLeTroll sont toujours un plaisir à lire

moi j'ai l'habitude de laisser le owner lors de la redefinition du constructeur

Code :

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

1
2
 
constructor Create(AOwner: TComponent; const AIdentifiant: string); reintroduce; virtual;

[ShaiLeTroll]

En fait, certaines formes héritées ont le label, d'autre pas, la référence lblPatientInfo étant rempli par la DFM (ou mis à nil au InitInstance), en fonction du Assigned, je lance ou pas le code commun de l'ancêtre.

Pour l'héritage, les fenêtres existaient avant que j'arrive, j'ai donc uniformiser les traitements par un ancêtre commun, je ne pensais pas allez si loin ... et j'avais pas envie non plus d'avoir un héritage complet (passer de DFM existante en object à inherited en cours de route, ça me semble bien risqué)

En théorie Objet, il n'y a rien de choquant, j'ai juste un membre d'un ancêtre qui est initialisé par les descendants, finalement ce qui dérange tout le monde, c'est que le chargement est fait via la DFM, ce qui implique donc probablement des ennuis avec l'IDE ...

et c'est avec plaisir que j'écris mes extravagances
D'ailleurs, j'ai ouvert ce topic pour cela, je trouvais franchement vilain ce que j'ai osé pondre, et j'ai ma confirmation, personne n'aime ... et comme je suis un Troll, je crois que je vais le garder

Pour le Owner, les fenêtres ne doivent pas (et peuvent pas) être utilisées en dehors de la Factory, c'est du ShowModal, le owner à nil, mais en général, je le conserve aussi ...

Tiens, personne n'a eu l'idée, mais j'aurais pu mettre un label dans chacune et dans l'ancètre et le retrouver avec un FindComponent !

[Kaféine]

Tiens, personne n'a eu l'idée, mais j'aurais pu mettre un label dans chacune et dans l'ancètre et le retrouver avec un FindComponent !

C'était le genre d'idée que j'avais eu...mais justement coller les label dans les descendants m'a amené à mon post précédent. (surtout si y'en a 50...)

Code :

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

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
29
30
31
32
33
34
35
36
 
type
  TfrmBase = class(TForm)
  private
    FId: string;
  protected
    function GetLabelPatientInfo: TLabel; virtual;
  public
    constructor Create(AOwner: TComponent; AId: string); reintroduce; virtual;
  end;
 
implementation
 
{ TfrmBase }
 
constructor TfrmBase.Create(AOwner: TComponent; AId: string);
begin
  inherited Create(AOwner);
  FId := AId;
  try
    GetLabelPatientInfo.Caption := 'Patient N°' + AId;
  except
   // rien à faire
  end;
end;
 
function TfrmBase.GetLabelPatientInfo: TLabel;
var
  C: TComponent;
begin
  C := FindComponent('lblPatientInfo');
  if (C <> nil) and (C is TLabel) then
    Result := TLabel(C)
  else
    raise Exception.Create('lblPatientInfo n''existe pas');
end;

[Montor]

et c'est avec plaisir que j'écris mes extravagances
D'ailleurs, j'ai ouvert ce topic pour cela, je trouvais franchement vilain ce que j'ai osé pondre, et j'ai ma confirmation, personne n'aime ... et comme je suis un Troll, je crois que je vais le garder

Il y a une telle usage sur mon projet avec deux type de construcreur aussi toute les formes utilisés sont derivés de TUserForm c'est un TForm sans DFM...voir BasicForm.pas
je voulais utiliser des interfaces mais ces derniers n'acceptent pas les properties.

[ShaiLeTroll]

Pour l'utilisation d'une classe héritée de TForm sans DFM, c'est un bon moyen pour architecturer son application et son comportement, mais as-tu comme moi déclarer des membres publiés pour les initialiser ensuite dans les DFM des classes héritées, c'est surtout cela que je trouvais tordus (surtout pour l'IDE, car maintenant, en y reflechissant d'un point vue purement objet, il n'y a rien d'incohérent)