Initialiser un Cadre

Bonjour,

J'ai un soucis que je traine depuis un moment.
Quelle est la bonne façon d'initialiser un cadre (TFrame).

Il n'y a pas de OnCreate.
J'ai essayé de surcharger le constructeur, mais je n'obtiens pas de bons résultats, l'accès à certaines propriétés (fixé au design) de certains contrôles semblant ne pas encore être initialisées (j'appelle pourtant le inherited en tout début).

Bref j'en suis réduit à créer une procédure Initialiser() que j'appelle dans le FormCreate qui contient le TFrame.
Mais ce genre d'appel est facile à oublier. Je n'aime donc pas cette solution.

Vous faites comment ?

Cordialement

Tu changes la propriété Align de ta frame dans ton constructor?

Tu peux être plus précis ? Car j'utilise les frames dans une grosse application (24 plugin tous développés avec des frames) et je ne rencontre pas de problème particulier (sauf pour le Align que je suis obligé de forcer après la création de la frame).

Salut,

Pour ma part, tous mes Frames sont crées et affichées dynamiquement

-> j'ai encapsulé les fonctions de créations de ces TFrames (dont le conteneur est soit un TForm soit un Txxx conteneur)

mes frames héritent toutes d'un TFrame générale, sur qui j'ai implémentée la méthode "OnCreate" qui est appelée depuis ma fonction d'encapsulation de création des Frames, dans laquelle après création de la frame, j'appelle mon OnCreate virtuel

-> résultat, je simule le OnCreate des Form mais sur mes Frames.

si ca peut donner des idées...

Salut :)

Citation:

---

Envoyé par Malatar

Tu peux être plus précis ? Car j'utilise les frames dans une grosse application (24 plugin tous développés avec des frames) et je ne rencontre pas de problème particulier (sauf pour le Align que je suis obligé de forcer après la création de la frame).

---

Tu veux dire des Frame contenus dans une DLL que tu affiches dans ta Fiche principale? Si c'est le cas, chuis drôlement intéressé ! ;)

Citation:

---

Envoyé par Pedro

Salut :)

Tu veux dire des Frame contenus dans une DLL que tu affiches dans ta Fiche principale? Si c'est le cas, chuis drôlement intéressé ! ;)

---

Pas dll mais Package (en utilisant les interfaces ^^)

Bonjour,

Citation:

---

Envoyé par TicTacToe

mes frames héritent toutes d'un TFrame générale, sur qui j'ai implémentée la méthode "OnCreate" qui est appelée depuis ma fonction d'encapsulation de création des Frames, dans laquelle après création de la frame, j'appelle mon OnCreate virtuel

---

Je vois que tu t'es posé la question comme moi et que tu l'as résolu comme moi : tu initialises à la main (de façon un peu plus centralisée).

Pour les autres, je vais essayer de mieux m'expliquer.

Si j'ai un TForm, qui contient un membre M de type TMonObjet qui doit être instancié durant toute la vie du Form et un label qui affiche la date.

Je ferais dans mon FormCreate :

Code:

---

1 2	M := TMonObjet.Create ; MonLabel.caption := DateToStr( Today );

---

et dans le FormDestroy

Code:

---

M.Free;

---

Voilà ! Peu importe comment et qui instancie la fenêtre (mon code, le code d'un collègue ou le framework Delphi), l'objet M sera forcemment bien créé et détruit, évitant toute fuite mémoire.

Un TFrame, c'est presque une fenêtre. Sauf qu'il n'y a pas d'évenements correspondant aux Create et Destroy (parce qu'un point de vue Delphi, il s'agit plus d'un contrôle que d'une fenêtre - ce qui se défend).

Comme je le disais, j'ai essayé de surcharger le constructeur Create de TFrame (TCustomFrame, en fait) , mais il semble qu'il est trop tôt pour accéder à certaines propriétés de certains sous-contrôles (par exemple, modifier par code le caption d'un TLable avec AutoSize à false, mais largement dimentionné, ne permettra pas d'afficher plus de caractères que le caption laissé par défaut dans l'EDI).

Comme TicTacToe, j'ai donc mis en place une politique de creation/destruction. Tous mes Frames, ont des méthodes Initialiser() et Finaliser(). Mais si j'oublie de les appeler (surtout le finaliser), je risque d'avoir des problème mémoire.

Comme je suis consciencieux, je n'ai pas de vrai problème. Mais je trouve quand même cette absence de OnTFrameCreate et OnTFrameDestoy génante et je me demandais si je n'étais pas passé à coté de quelque chose.

Cordialement.

Salut:)
Sinon, y a ça aussi:
http://delphi.developpez.com/faq/?pa...estroysurframe
:P

Citation:

---

Envoyé par VanQuish

Comme TicTacToe, j'ai donc mis en place une politique de creation/destruction. Tous mes Frames, ont des méthodes Initialiser() et Finaliser(). Mais si j'oublie de les appeler (surtout le finaliser), je risque d'avoir des problème mémoire.

---

En fait pour ma part je ne peux pas oublier de finaliser.
La méthode qui crée ma Frame dans son conteneur est une méthode de classe définie dans mon TFrame.
1. Cree la Frame
2. Appelle "TMaClasseFrame.OnCreate"
3. La destruction se fait toute seule, par sont propriétaire, et dans le cas ou le propriétaire est une form, dans le OnDestroy de la form, lance un message à la frame, qui appele un 'Mydestroy' (méthode de classe aussi) et qui appelle également en symétrie le 'OnDestroy' virtuel de ma Frame.
4. Est définie au plus haut niveau de ma hiérachie des classes TFrame mais virtuelle pour le besoin des Frames + spécifiques.

Donc en fait, la finalisation d'une frame est toujours appelée lors de la destruction du conteneur (en chaine donc), ou au besoin, appelée manuellement.
-> un seul appel à la construction de la Frame, le reste est fait tout seul et rien de spécial n'est à définir dans une Frame enfant (si ce n'est le spécifique)

L'init, bin si je l'appelle pas, la Frame n'est pas allouée et affichée, alors pas possible de l'oublier ! :)

Enfin, c'est vrai que ce n'est pas simple comme problème, pour construire quelquechose de solide fiable et efficace, il y a mine de rien beaucoup de comibinaison possible (à gerer avec des form modale ET non modales...) ;)

Citation:

---

Envoyé par Pedro

Sinon, y a ça aussi:
http://delphi.developpez.com/faq/?pa...estroysurframe

---

Merci mais comme je l'expliquais, cela fonctionne mal pour une certain nombre de choses - et c'est sans aucun doute la raison pour laquelle Borland n'a pas mis d'evenement OnCreate et OnDestroy.

Citation:

---

Envoyé par TicTacToe

Enfin, c'est vrai que ce n'est pas simple comme problème

---

On n'est d'accord. J'avais peur d'être passé à coté d'une évidence, mais ce n'est pas le cas.

Merci pour vos réponse.

Citation:

---

Envoyé par vanquish

Merci mais comme je l'expliquais, cela fonctionne mal pour une certain nombre de choses - et c'est sans aucun doute la raison pour laquelle Borland n'a pas mis d'evenement OnCreate et OnDestroy.

---

Si tu as utilisé ce code et qu'il t'a posé un(des) problème(s), je voudrais bien savoir le(s)quel(s). On pourrait ainsi étoffer cette QR ;)