Version imprimable
Bonjour à tous
Je suis en train de concevoir un petit soft ambitieux dans lequel chaque item géré s'appuie sur un ttabsheet.
A cet effet, j'ai peuplé le ttabsheet avec d'autres composants, et je souhaite me servir de ce ttabsheet comme d'une matrice que je duplique sur une nouvelle page dès que j'en ai besoin.
Quels sont l'art et la manière de faire ce genre de chose ?
Merci de vos conseils.
Bonjour,
pourquoi ne pas utiliser un TFrame pour cela, je pense que ce serai plus adapté, quitte à l'afficher à l'intérieur d'un TTAbsheet.
@++
Dany
merci pour ta réponse.
je vais étudier...
Cependant, si le tframe parait adapté, comment faire pour faire une création "par héritage" et profiter de la matrice ?
Dois-je aller jusqu'à me créer un compo sous l'IDE que je pourrais ensuite créer à ma guise dans mon appli, comme on peut le faire avec les compos borland ?
Bonjour,
Je n'ai peut-être pas bien compris la question. Le TFrame permet de regrouper un certains nombre de composants, c'est un peut un TForm, mais en plus léger. Ensuite le TFrame que tu as créé peut-être posé dans un TForm, un TPanel ou n'importe quel conteneur (il faut prendre le composant Cadre ou frames suivant la version de Delphi que tu as dans l'onglet Standard). Le composant que tu as alors posé peux être modifié localement, tu peux changer la position d'origine de chaque composant posé dessus, ajouter ou enlever des composants, ajouter ou enlever des évennements, sans pour autant impacter le TFrame et les instances posées sur d'autres formulaires.
Tu peux aussi créer dynamiquement ce TFrame, comme n'importe quel autre composant.
@++
Dany
Dany a raison, dans ce cas le TFrame est parfaitement adapté à ce type de situation.
Pour aller plus loin et t'en convaincre, il te suffit de placer un TFrame dans un nouveau projet. De l'agrementer des composants que tu désires utiliser dans tes tabsheet.
D'y enregistrer la classe dans la section initialization
De créer ensuite la référence de classe suivante :Code:
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
TFrameClass = class of TFrame;
Dès lors tu pourras appeler simplement et dynamiquement la frame et la placer dans le tabsheet de la façon suivante :
Par ailleurs, tu pourras également dériver ta frame initiale et ainsi la doter de nouveau composants et ou de nouveau traitements.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Toujours pareil, un petit RegisterClass dans la section initialization.Code:
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
Puis l'appel de cette frame dérivée de la façon suivante grâce à la référence de classe.
En déclarant bien entendu unit3 dans les uses.Code:
2
Tout ceci dans le cas où tu désires créer dynamiquement ces TFrame.
Pour les placer directement sur les TabSheet en design-time, tu utilises le composant Frames disponible dans la palette d'outils.
Dernière solution tu peux directement ajouter ton TFrame ainsi que ses dérivés dans la palette d'outils et ainsi ils seront disponibles comme tous les composants.
Ouep, ouep...
je commence à y voir plus clair :roll:
Question supplémentaire : comment ça se passe pour les procédures liées aux événements ?
Ainsi, soit un bouton contenu dans un TFrame, où doit se faire le "cablage" du OnClick ?
1/ dans le compo MonTFrame ? (pour autant que se soit possible) mais alors, comment distinguer les différents boutons des différents TFrames ?
2/ lors de la création du tabsheet par "import" du TFrame via la pré-déclaration d'une procédure banalisée OnClick ? Mais dans ce cas, comment gérer le Sender? (peut-on avoir la main sur le name du bouton ?)
3/ ailleurs / autrement ?
Peut-être par le couple nom du composant et nom du tabsheet dans lequel la frame se trouve :Citation:
Envoyé par qi130
J'ai un petite question. Dans ton applicatif, tes tabsheet seront créés dynamiquement au run-time ou alors ils seront tous définis au design-time ?Code:
2
3
4
5
6
Ils seront tous définis au fur et à mesure des besoins, donc au runtime.
Est-ce de près ou de loin ce que tu désires réaliser ?
Oui, c'est le même principe de fonctionnement.
Au passage, (j'ai pas regardé ton code :oops:), qd on switche entre 2 tab de type frame 2, l'edit s'enrichit tout seul...
Effectivement, l'edit s'enrichit ;)Citation:
Envoyé par qi130
Bon, j'ai jeté un œil attentif à ton projet, et c'est bien ça qu'il me faut :P
Je vais donc creuser les TFrames et faire un effort supplémentaire de conception pour spécifier ma matrice "au cordeau" et câbler les événements ;)
Au passage, chaque frame comportera 2 TPagecontrol qui devront fonctionner avec des tabsheet dynamiques. Je serai donc amené à produire la même approche (mais je pense avoir pigé).
Pour ces 2 "sous-frames", penses-tu possible d'avoir du code générique qui ne serait pas embarqué dans l'unité dédiée à chaque frame (genre dans un Datamodule) ?
A la réflexion, n'est-ce pas le rôle de l'unit4 :roll: de ton projet?Code:
2
A mon avis, si le code est générique autant l'avoir dans les frames.Citation:
Envoyé par qi130
Par ailleurs, et grâce à l'héritage, il est possible de redéfinir ou surcharger un ou plusieurs comportements spécifiques pour un ou plusieurs composants tout en bénéficiant de la partie générique commune aux deux classes.
Dans l'unité Unit2 de l'exemple on définit la procédure Button1Click, en revanche dans l'unité 3 on a pas besoin de la définir, elle le sera par défaut. En modifiant seulement la procédure virtuelle monAction on redéfinit le comportement que l'on aura si l'on clique sur ce bouton.
L'unité 4 recense les interfaces objets donc on définit ce que "sait faire une frame". Voir l'edit qui s'enrichit (PageControl1Changing de l'unité 1).Citation:
Envoyé par qi130
Cela permet d'obtenir une sorte de signature pour chaque type de frame. Par ailleurs, on n'a pas besoin de connaître avec précision la classe de l'instance avec laquelle on travaille.
Dans le cas de l'exemple de code que je t'ai fourni (procedure PageControl1Changing ), on récupère un TComponent puis on lui demande s'il supporte une interface objet précise.
Si c'est le cas, on lui demande alors d'exécuter une procédure dont la "signature" est définie dans cette interface objet.
Ok....
Pour la signature que tu évoques, elle est assimilable au GUID mentionné dans ton code ?
Oui c'est grâce au GUID que la mécanique fonctionne, voir la fonction Supports. Sans GUID la fonction Supports échoue.Citation:
Envoyé par qi130
Au fait, j'ai employé le terme de signature à tort, j'aurais du plutôt employer le terme de contrat.
Bon, ben, yapluka :lol:
Merci pour l'ensemble de tes apports.