Pourquoi créer un composant dynamiquement?
Résolu/Fermé
rosy01
Messages postés
39
Date d'inscription
dimanche 10 novembre 2013
Statut
Membre
Dernière intervention
21 juin 2014
-
Modifié par rosy01 le 19/04/2014 à 17:15
rosy01 Messages postés 39 Date d'inscription dimanche 10 novembre 2013 Statut Membre Dernière intervention 21 juin 2014 - 20 avril 2014 à 12:14
rosy01 Messages postés 39 Date d'inscription dimanche 10 novembre 2013 Statut Membre Dernière intervention 21 juin 2014 - 20 avril 2014 à 12:14
A voir également:
- Pourquoi créer un composant dynamiquement?
- Créer un compte gmail - Guide
- Créer un compte google - Guide
- Créer un groupe whatsapp - Guide
- Créer un compte instagram - Guide
- Test composant pc - Guide
2 réponses
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
20 avril 2014 à 11:13
20 avril 2014 à 11:13
Bonjour,
Hé bien, l'intérêt de l'objet étant entre autre de pouvoir l'employer sans qu'il soit complètement défini et donc d'implémenter des objets inexistants à la conception, cette possibilité se manifeste aussi avec les composants, et la création dynamique permet donc d'employer n'importe quel composant même non encore écrit...
Par ailleurs, les composants peuvent être très lourds et long à initialiser, et sachant que chaque boîte de dialogue est un composant qui en intègre d'autres à son tour, il serait inutile et coûteux en ressource de tout créer dès le lancement du programme... à quoi bon occuper de la mémoire en permanence et prendre le temps d'initialiser une boîte de dialogue «à propos...» qui ne sert pour ainsi dire jamais?
De plus, les composants sous delphi, comme toute classe dérivées de TPersistent, lisent leur propriétés à partir d'un flux (fichier de ressources) donc il est possible de modifier leurs paramètres après qu'ils soient garnis, il suffit pour ça d'intervenir au bon moment dans les événements constructeurs (OnCreate, OnShow..) et tout composant peut voir ses propriétés modifiées pour peu qu'elles soient ouvertes à l'écriture, tout dépend de la déclaration des champs: par exemple tout objet est activable et désactivable avec son champ "enabled", à la conception comme à l'exécution.
Pour l'exemple, on pourrait imaginer un logiciel de dessin qui utilise des composants pour définir les différents outils: l'intérêt résiderait dans le fait d'utiliser l'inspecteur d'objet pour les distinguer, et il serait possible de mettre à jour la liste et les propriétés de ces outils simplement en remplaçant un fichier de ressource (à priori, mais j'ai jamais essayé). Dans ce cas précis, l'intérêt de créer les composants dynamiquement est aussi évident puisqu'on utilise un seul outil à la fois et qu'ils peuvent être très nombreux...
Il faut imaginer qu'un composant est simplement une classe avec des propriétés publiées -donc facilement paramétrable avec l'inspecteur d'objet- et dont le code est partagé comme dans le cas d'une dll (via les paquets d'exécution) et on peut très bien les utiliser de manière très souple et en assez grand nombre, dès lors qu'on a besoin d'objets très spécialisés et facilement paramétrables, donc à partir du moment ou on sort du schéma basique de la fiche unique la création dynamique prend tout son sens...
Hé bien, l'intérêt de l'objet étant entre autre de pouvoir l'employer sans qu'il soit complètement défini et donc d'implémenter des objets inexistants à la conception, cette possibilité se manifeste aussi avec les composants, et la création dynamique permet donc d'employer n'importe quel composant même non encore écrit...
Par ailleurs, les composants peuvent être très lourds et long à initialiser, et sachant que chaque boîte de dialogue est un composant qui en intègre d'autres à son tour, il serait inutile et coûteux en ressource de tout créer dès le lancement du programme... à quoi bon occuper de la mémoire en permanence et prendre le temps d'initialiser une boîte de dialogue «à propos...» qui ne sert pour ainsi dire jamais?
De plus, les composants sous delphi, comme toute classe dérivées de TPersistent, lisent leur propriétés à partir d'un flux (fichier de ressources) donc il est possible de modifier leurs paramètres après qu'ils soient garnis, il suffit pour ça d'intervenir au bon moment dans les événements constructeurs (OnCreate, OnShow..) et tout composant peut voir ses propriétés modifiées pour peu qu'elles soient ouvertes à l'écriture, tout dépend de la déclaration des champs: par exemple tout objet est activable et désactivable avec son champ "enabled", à la conception comme à l'exécution.
Pour l'exemple, on pourrait imaginer un logiciel de dessin qui utilise des composants pour définir les différents outils: l'intérêt résiderait dans le fait d'utiliser l'inspecteur d'objet pour les distinguer, et il serait possible de mettre à jour la liste et les propriétés de ces outils simplement en remplaçant un fichier de ressource (à priori, mais j'ai jamais essayé). Dans ce cas précis, l'intérêt de créer les composants dynamiquement est aussi évident puisqu'on utilise un seul outil à la fois et qu'ils peuvent être très nombreux...
Il faut imaginer qu'un composant est simplement une classe avec des propriétés publiées -donc facilement paramétrable avec l'inspecteur d'objet- et dont le code est partagé comme dans le cas d'une dll (via les paquets d'exécution) et on peut très bien les utiliser de manière très souple et en assez grand nombre, dès lors qu'on a besoin d'objets très spécialisés et facilement paramétrables, donc à partir du moment ou on sort du schéma basique de la fiche unique la création dynamique prend tout son sens...
rosy01
Messages postés
39
Date d'inscription
dimanche 10 novembre 2013
Statut
Membre
Dernière intervention
21 juin 2014
20 avril 2014 à 12:14
20 avril 2014 à 12:14
Une explication très claire, merci beaucoup.
