transmettre des infos entre 2 forms ?

bonsoir,

dans mon appli, j'ai une form principale et une form pour la configuration.

Dans la form principale, j'initialise une structure avec diverses infos, et j'aimerais pouvoir accéder a ces infos sur ma deuxième form.

1) Quelle est la meilleure solution et la plus propre pour transmettre cette structure ?

2) Et aussi, quand je ferme la 2ème form, comment puis-je transmettre diverses infos à la première (par exemple, si l'utilisateur a cliqué sur le bouton annuler) ?

merci

miky

tu mets tes infos dans une classe séparée dans un fichier different.

- form_principale.cpp
- form_config.cpp
- class_infos.cpp

1) tu fais un include du class_infos.h dans les deux form's
2) tu crée une instance de class_infos dans form_principale
3) tu transmets un ptr sur l'instance de class_infos à form_config

form_config travaille directement avec les données et quand tu close les données sont a jour dans class_infos

Salut
une autre possibilité
soit
F1 Pointeur sur ta form1;
F2 Pointeur sur ta form2

f2 est crée statiquement ou dynamiquement dans F1

dans la partie publique de Form2 inclus une Variable du type de ta structure
ex
TMastructure Mastructure;

ce qui te permet depuis F1 d'avoir un accès complet sur Mastructure

ex

Code:

---

1 2 3 4 5 6 7

void __fastcall TF1::Button1Click(TObject *Sender) { TForm2 F2= new TForm2(NULL); //Lecture de la structure TMastructure mstruct= F2->Mastructure; }

---

cordialement

merci à vous deux pour la réponse.

Et pour récupérer des infos depuis la 2ème form dans le cas ou elle n'est pas modale ? Est-ce l'utilisation de message peut être une solution adaptée pour la communication entre 2 fenêtres ?

Alors moi je fais tout ca comme un gros port!
dans unit1.cpp :

Code:

---

#include "Unit2.h"

---

Comme ca avec Form2->Label1->Caption j'accède à la propriété Caption du babel1 de la form2 depuis la form1.
et dans unit2.cpp :

Code:

---

#include "Unit1.h"

---

Comme ca, ca marche aussi dans l'autre sens.

Malheureusement, parfois le lieur m'informe que certaine déclaration de fichier .OBJ sont en double. Mais c'est rare.

Alors ca c'est uniquement si tu es le seul à bosser sur ton programme, que tu te fouts des standards, le mémoire et compagnie. Tu accèdes à tout très facilement.

Vous l'avez compris, je suis pas un expert :D

Citation:

---

Envoyé par mikyfpc

merci à vous deux pour la réponse.
Et pour récupérer des infos depuis la 2ème form dans le cas ou elle n'est pas modale ?

---

Tout dépend de son cycle de vie. Si tu détruis la fenêtre en la fermant, il faut stocker son contenu quelque part (peut-être en t'inspirant du modèle Vue-Document des MFC). Si tu utilises la gestion standard des fenêtres de BCB, la fenêtre n'est pas détruite quand elle est fermée, mais seulement cachée. Ses champs et méthodes publics sont donc toujours accessibles.

Citation:

---

Est-ce l'utilisation de message peut être une solution adaptée pour la communication entre 2 fenêtres ?

---

L'utilisation de messages est en effet une solution envisageable.
Elle présente l'avantage, si elle est bien faite, de découpler les classes encapsulant les fenêtre et les dialogues (ce qui facilite leur réutilisation).

En général, ce type de solution passe par la mise en place d'agents prenant en charge la répartition des messages et le guidage fonctionnel de l'application, ou de simples composants de guidage selon le cas. Mais elle a comme inconvénient d'alourdir le code et de demander une architecture d'échange de messages assez claire pour éviter les ennuis.

Si ton application est simple, il n'est sans doute pas utile de trop en faire.
Personnellement, j'ai renoncé aux architectures à messages, trop compliquées à mon goût pour les avantages qu'elles apportent. Par contre, j'utilise des agents fonctionnels (un agent par fenêtre en général : les fenêtres gèrent toute la présentation et éventuellement les contrôles de saisie simples, les agents gèrent les traitements et les enchaînements entre fenêtres). L'utilisation ponctuelle du modèle Observateur permet de compléter avec une gestion de messages en cas de besoin.

l'idee de DjmSoftware est probablement la meilleure.

Ca te permet de pas ecrire directement sur l'original. Comme ca si l'utilisateur veut annuler, c'est mieux. Tu ecrases l'original seulement si il clique sur OK grace au pointeur et au duplicata.

Par contre, evite de faire ca avec des instances multiples. Sinon t'es bon pour t'etrangler tout seul.

j'ai trouve que la solution suivante qui consiste a limiter le nombre d'instances d'une fenetre: variable globales dans la classe parent.

if(mdichild := null) show(mdichild) else new mdichild

et de gerer un event qui informe la classe parent que mdichild est detruit et de remettre la variable a null

et si il y a une histoire de partage ben la t'es obligé de faire un checksum de la structure et de verifier avant ecriture si ca correspond comme dans une database.....

si t'es en multithread je te laisse t'amuser.

merci pour vos réponses, je vais étudier tout ca et prendre la solution la plus adaptée à mon appli :)

miky