COMPOSANT DYNAMIQUE : COMMENT CODER POUR UN COMPOS NON ENCORE CRÉÉ
florenth
-
18 avril 2006 à 20:15
lord948 Messages postés 34 Date d'inscription jeudi 17 janvier 2008 Statut Membre Dernière intervention 19 mai 2009 - 8 janv. 2009 à 02:59
lord948 Messages postés 34 Date d'inscription jeudi 17 janvier 2008 Statut Membre Dernière intervention 19 mai 2009 - 8 janv. 2009 à 02:59
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/37127-composant-dynamique-comment-coder-pour-un-compos-non-encore-cree
https://codes-sources.commentcamarche.net/source/37127-composant-dynamique-comment-coder-pour-un-compos-non-encore-cree
8 janv. 2009 à 02:59
22 avril 2006 à 21:29
Je ne proposait cette méthode que pour la faire coonnaitre. J'utilise régulièrement la création dynamique et quand ce n'est que pour quelques objets j'utilise bien sur le transtypage et les objet existants ( TComponent.Components, TWinControl.Controls ).
Mais dans le cas d'un grand nombre avec des besoin particulier un héritage est bien mieux adapté.
PS : je viens te voir ici vu que l'on ne te vois pas beaucoup là ba. :wink:
21 avril 2006 à 23:31
Comme la création dynamique de composants, leur sauvegarde et leur restauration à partir d'un flux fichier est un sujet sur lequel nous avons collaboré, j'invite les curieux à se rendre à cette adresse : http://tinyurl.com/k72zj
Toutefois, voici un point sur lequel je suis un peu moins d'accord quand il écrit "Tu dérives une classe descendante de TObjectList ou même un TComponentList et tu n'as plus rien à transtyper non plus."
Je trouve que c'est se donner beaucoup de mal quand on n'a besoin que de deux ou trois méthodes de TObjectList, TComponentList ou autres semblables. Il faut pratiquement surcharger toutes les méthodes alors qu'elles ont été définies comme statiques par les concepteurs de la VCL.
Dans ces cas là, je vous conseille d'opter pour la composition et non l'héritage.
Caribensila a écrit : "j'avais rencontré des problèmes pour traiter les événements des compos créés après un 'ReadComponentResFile' dans le code"
Quand tu affectes une méthode à un évènement, tu affectes en réalité un pointeur de méthode. Si au cours de la session courante de ton logiciel tu affectes Nil puis que tu affectes de nouveau une méthode à un évènement, pas de problème. Mais comme les exe sont relogeables et rien ne permet de dire que la session suivante s'effectuera avec les mêmes adresses mémoire, je te laisse imaginer les dégâts que cela pourrait causer si tu affectais une adresse qui ne serait alors plus valide !...
GPF garantie 8-S
21 avril 2006 à 19:21
Moi, j'avais rencontré des problèmes pour traiter les événements des compos créés après un 'ReadComponentResFile' dans le code...
Par exemple, on 'Read' un TPanel contenant un TImage et :
MyImage.OnMouseDown := Action1Execute; // ne fonctionne pas!
Par contre, ça, ça fonctionne:
(MonPanel.Components[0] as TImage).OnMouseDown := Action1Execute;
Je ne comprends très bien pkoi.
Un exemple pourrait aider des débutants, je pense...
21 avril 2006 à 18:37
je vais vous poster un exemple , faites moi svp un cahier des charges -- serieux je rigole pas !
21 avril 2006 à 07:08
21 avril 2006 à 00:15
Imagine une visionneuse de diapos miniatures, par exemple...
Exactement, et il y a des tas d'autres cas... Je rejoints DelphiProg sur les TObjectList. Tu dérives une classe descendante de TObjectList ou même un TComponentList et tu n'as plus rien à transtyper non plus.
19 avril 2006 à 14:32
"la création dynamique de compos est toujours d'actualité?"
Imagine une visionneuse de diapos miniatures, par exemple...
Mais bon! Je ne me défends pas, Je n'étais pas inspiré et c'est faiblard... Ok pour la cure de vitalines C++ lol
...Et ça a au moins le mérite de me remettre les idées en place.
Merci à tous.
19 avril 2006 à 14:20
JulioDelphi > Ton idée est pas mal (d'alleurs c'est celle que j'utilise ...) disons que ça évite le transtypage obligatoire que l'on a avec le TObjectList et autres. Mais, sinon, à part ce petit avantage, on ne peut pas manipuler la liste aussi facilement.
Mais entre nous, on peut le dire, la liste de composants, on la laisse dans l'ordre du début.
++
19 avril 2006 à 14:15
Mais pour le reste on est d'accord, tu te sers soit du conteneur (parent) pour acceder aux objets, soit, si ceux cis te gènent dans ton code, tu prend, comme l'a dit Delphipro, un TObjectList ou un TComponentList.
Mais, là, et je ne voudrais pas polémiquer sur le sujet, mais je n'ai jamais eu besoin de creer plein (en tout cas, un nombre incconnu) de composants dynamiquement,alors je me demandais si la création dynamique de compos est toujours d'actualité ?
18 avril 2006 à 23:39
La VCL propose un certain nombre de conteneurs tels que TList, TObjectList ou encore TComponentList.
D'ailleurs, la propriété Components des objets dits "containers" n'est-elle pas une liste de références ?
Caribensila, je trouve que ta forme baisse ces derniers temps ;o)
Une petite cure de vitamines te ferait le plus grand bien, lol.
18 avril 2006 à 22:07
18 avril 2006 à 21:07
for i:=0 to 1 do
begin
NewEdit[i] := TEdit.Create(Panel1);
NewEdit[i].Parent := Panel1;
NewEdit[i].Left := 4;
NewEdit[i].Top := 4+(i*20); // pour les espacer
end;
puis je fais appel a eux comme ceci :
NewEdit[x].Text := 'Bonjour !';
voila. fais-je bien ou pas ?
18 avril 2006 à 20:15
Pourquoi faire sompliqué quand on peut faire simple ?
Ttu mets ta variable NewEdit dans la section "public" de la déclaration de la fiche et hop ! plus de problèmes !
Et puis ton cas ne marche que pour un panel => un edit.
C'est plus trop dynamique tout ça puisque le panel doit déjà être présent.
Allez, comme je dis toujours: si tu ne te plantes pas, tu ne pousseras jamais ...