aOwner dans les constructeurs de composants

Bonjour,

Un petit éclaircissement sur le constructeur des composants :

Lorsqu'on définit constructor TmyComponent.Create(aOwner: TComponent), TmyComponent étant "posé" sur une Form ou un élément de celle-ci (TPanel,...), le aOwner "renvoyé" est-il systématiquement une TForm ? Sinon que peut-il être d'autre ?

Merci. Cordialement.
Gilles
Lazarus 1.1-37477 fpc-2.6.1-20120602-Win32

ça fait un moment que je n'ai pas touché lazarus ou delphi mais tu peux faire ça si tu veux, je pense :

Code:

---

1 2 3 4 5 6 7

procedure TForm1.FormCreate(Sender: TObject); begin label1:=TLabel.create(panel1); label1.parent:=panel1; label1.caption:='mon propriétaire est panel1'; end;

---

Ceci dit, si tu mets self, form1 devrait se charger de libérer ton label dynamique. C'est l'avantage. Cependant, ça doit se faire aussi en cascade...

@+

Bonjour,

Merci pour votre réponse. J'aimerais savoir s'il se peut que le aOwner du composant renvoie une autre réponse que la TForm sur laquelle il est posé lorsque l'on interroge le aOwner.

Dans la configuration suivante, le myComponent1.Parent est Panel1. Son aOwner est Form1.
Form1
--|__Panel1
-------|__myComposant1

Mais est-il possible que dans certaines (autres) circonstances, le aOwner ne soit pas la TForm ? Autrement dit, est-il nécessaire de vérifier que le aOwner est bien une TForm ? Et dans le cas où ce ne serait pas la TForm, quelles sont ces circonstances ?

Cordialement. Gilles

Regarde peut-être du côté de FindComponent...

Bonsoir,

Pourquoi as-tu besoin de compter sur le fait que le Owner soit une fiche ?

Et si c'est le cas, n'est-il pas dangereux de l'assumer au cas où lors d'une création dynamique on assigne nil, par exemple.

Cela dit, si ce besoin ne se situe que lors de la création en Design Time, il suffit de tester dans le code :

Code:

---

1 2 3

if csDesigning in ComponentState then // je suis bien en création de fiche, et mon Owner est fatalement (?) une fiche else // je ne suis pas sûr de la nature de mon Owner

---

Bonjour Toulourou,

J'ai dérivé une partie de mes composants visuels pour diverses raisons, notamment, celle qui est à l'origine de ma question : je veux que le Enter puisse avoir la même fonction que le Tab.

Dans un premier temps, je me suis facilité la tâche dans ma propre activité de programmation en dérivant les composants standards pour les adapter à mes besoins usuels, sans laisser trainer des codes répétitifs indispensables mais "loins de la couche métier". Maintenant, j'améliore l'ergonomie pour l'utilisateur.

J'ai donc dans mes composants, une méthode de ce type :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

procedure TmyEdit.SelfOnKeyPress(Sender: TObject; var Key: char); begin if Assigned(FOnKeyPress) then FOnKeyPress(Sender); if (FEnterKeyIsNext) and (not (ReadOnly)) and (Enabled) and not (csDesigning in ComponentState) then begin   if Key = #13 then begin with bForm do if HiWord(GetKeyState(VK_SHIFT)) <> 0 then SelectNext(ActiveControl, False, True) else SelectNext(ActiveControl, True, True); Key := #0 end;   end; end;

---

Elle repose sur SelectNext qui nécessite une TForm. Le bForm ci-dessus est défini dans le constructeur :

Code:

---

1 2 3 4 5 6 7 8

constructor TmyEdit.Create(aOwner: TComponent); begin inherited; bOwner := aOwner; if bOwner is TForm then bForm := TForm(bOwner) else Showmessage('Le aOwner n''est pas une Tform : ?'); [...] end;

---

J'utilise ces composants depuis pas mal de temps et je n'ai jamais rencontré de problème (ie le ''Le aOwner n''est pas une Tform : ?' n'est jamais apparu). Mais comme je les revisitais, la question que j'avais éludée est aujourd'hui d'actualité. [RQ : j'ai besoin d'utiliser aOwner dans d'autres méthodes du composant, d'où la présence de bOwner].

Avec ces composants, je n'utilise pas la création dynamique. Ils sont systématiquement "déposés à la souris" sur une TForm.

Cordialement. Gilles

Bonjour

Je connais au moins un cas où le Owner peut être autre chose qu'une TForm, même en se limitant à la conception visuelle, c'est s'il est une TFrame.

au lieu d'imposer que le parent soit un TForm il suffit de ne faire le traitement QUE si le parent est un TForm ;)

et il existe une fonction pour retrouver la fiche parente : GetParentForm ou ValidParentForm qui déclenche une exception s'il ne trouve pas de fiche parent

Bonjour,

De toute façon, dans le cadre de l'exemple donné, l'utilisation de Frame semble poser un problème :

Supposons que dans Form1, je place Edit1 (TabOrder =0) et Edit2 (TabOrder = 1)
et dans Frame1 (incorporée dans Form1), Edit3 (TabOder = 0) et Edit4 (TabOder = 1).

Maintenant, en appuyant sur la touche Tab, je voudrais parcourir mes TEdits dans l'ordre suivant : 1-3-2-4. Le SelectNext n'est pas opérationnel. Je ne veux pas coder les OnKeyxxxx de chaque TEdit, autrement dit le faire à la main pour imposer la séquence retenue. Or, il faudrait -je ne sais pas comment -pouvoir préciser le TabOrder de son choix notamment la limite inférieure de ceux des TEdits de la Frame1 qui est toujours 0- et ensuite rendre le SelectNext opérationnel "dans la même foulée" aussi bien sur les Form1.TEdits que sur les Frame1.TEdits.

Ou alors comme j'utilise que des objets visiuels dérivés, je pourrais y intégrer ma propre propriété TabOrder et inclure mon propre SelectNext. Cela me semble assez facile à réaliser. Je réfléchis à l'intéret de la question... mais comme c'est pour mon usage personnel, j'éviterai les Frames que de toute façon je n'utilise pas. J'avais fait un test et dans le cadre de mes projets et surtout de mes habitudes "d'écriture", je n'ai pas vu alors l'intéret de leur utilisation... en tout cas la méthode de programmation imposée semblait me compliquer le développement plutôt que de le simplifier. Mais évidemment, cela doit varier selon chaque programmeur et les tâches qu'il a à réaliser.

Merci pour vos réponses.
Cordialement. Gilles

ne suffit-il pas de changer Key de #13 en #9 dans le code ?!

les frames c'est pourtant super pratique quand tu veux créer un pseudo composant, ça déporte tout le code associé dans une nouvelle unité et décharge l'unité principale.

par exemple mon unité GLFrame qui crée une fenêtre OpenGL dans un TFrame qui contient tout le code d'initialisation, il ne reste dans la fiche principale qu'à mettre le code du Paint.

Bonjour,

Je ne discute pas l'utilité des TFrames... Je ne m'en sers pas... J'utilise des TPanels... et dans ce cas, l'intêret d'utiliser des Frames me semble limité : il faut redéfinir les uses, l'interface...

Remplacer #13 par #9. Oui c'est envisageable mais appliqué à un TMemo (géré également ainsi), il ne faudra pas oublier de rebasculer "au bon moment" par exemple pour tenir compte des WantTabs et autres WantReturns...

Cordialement. Gilles