Discussion :

[Sieur_Blabla]

Bonjour,

Je sollicite votre aide pour savoir s'il est possible d'utiliser les objets d'une classe dans une autre classe.
J'ai une fenêtre, qui après un clic sur un bouton ouvre une autre fenêtre, qui est en fait une boite de dialogue. Je voudrais utiliser les noms des widgets de la main window dans cette boite de dialogue. Mais je n'y arrive pas.

Comment faire svp?

[Invité]

Utilise l'amitié entre les classes avec le mot-clé friend.

[Sieur_Blabla]

Merci pour ta réponse. STP, tu peux me donner plus de détails sur le mot clé friend.
Merci.

[Invité]

FAQ C++ --> http://cpp.developpez.com/faq/cpp/?page=friend

[LittleWhite]

Bonjour,

J'ai un petit doute sur le friend ( enfin, je veux dire que cela ne me semble pas la meilleure solution )
Habituellement, lorsque j'ai besoin de passer des informations aux Dialogs, j'utilise le constructeur pour cela ( je peux aussi le faire avec des setters )
Sinon, si on veut récupéré des valeurs de la Dialog, moi, j'utilise des getters selon le principe suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
void monSlotQuiEstTropBeau(void)
{
    int retour = 0;
 
    MyDialog md(param1,param2,...,this);
 
    // Exemple possible
    md.setParam42(42);
 
    retour = md.exec();
 
    if ( retour == Qt::Accepted )
    {
        // Autre exemple
        var1 = md.getParam1();
    }
    else
    {
        // L'utilisateur a annulé ou autre donc je ne fais rien et je ne garde pas les paramètres
    }
 
    // Ici le destructeur est appelé car c'est une variable locale :)
}

Voilà comment je fais ... mais je ne sais pas si c'est le mieux, mais perso je prefère ça aux firends

[Invité]

Le soucis c'est qu'avec les accesseurs et mutateurs, ce ne sont pas les deux classes qui ont accès à ces éléments mais tout le code. L'amitié corrige ce problème, ce n'est pas pour rien si ce concept existe.

[gbdivers]

Bonjour

Personnellement, je pense qu'utiliser friend ici imposerait un couplage fort entre la classe parent et la classe dialogue (ce qui obligerait par exemple à modifier le code de la seconde si on ajoute ou supprime un widget dans la fenêtre) et briserait un peu l'encapsulation (soit les widgets ont besoin d'être accessible en dehors de la fenêtre et on conçoit la classe fenêtre en conséquence, soit on souhaite que ça ne soit pas le cas et on "cache" l'accès).

Les mutateurs/accesseurs sont mieux dans ce sens puisse qu'ils respectent mieux la conception de la classe et l'encapsulation.

Il y a aussi la possibilité d'utiliser les signaux/slots ou les events si tu souhaites avoir un échange de paramètres "en temps réel" (par exemple une boite de dialogue qui permettrait de choisir la couleur d'un widget, le choix étant directement visible dans la fenêtre sans avoir besoin de cliquer sur "ok")

[Sieur_Blabla]

Bonjour,

J'ai essayé la technique friend. Elle ne marche pas bien. Le contenu que je veux échanger de la main window à la dialogue est le contenu d'une comboBox.
Quand je fais juste friend class DialogBox, il ne reconnait quand même pas le nom de ma comboBox.
J'ai essayé friend QComboBox combo, mais il me sort le message suivant:
combo is neither function nor member function; cannot be declared friend.

J'ai essayé aussi, la seconde technique, mais elle ne marche pas non plus dans mon cas. Peut être parce que je code la boîte de dialogue dans un autre fichier. Un #include "mainWindow.h" ne suffit pas.

Merci.

[Invité]

Tu ne peux quand même pas déclarer une classe de Qt comme ami de ta classe. C'est juste pour tes propres classes. Hérite de QComboBox dans ce cas.

[Sieur_Blabla]

Ah c'est pas possible alors! Ok, je vais essayer l'héritage.

Merci.

[_skip]

Le contenu que je veux échanger de la main window à la dialogue est le contenu d'une comboBox.

Dans ce cas, pourquoi tu passerais pas simplement au constructeur de ta boîte de dialogue la liste des options?
Ainsi tu diminues le couplage. Perso je rejoins gbdivers au sujet du "friend", je trouve que ça mène à du code spaghetti.

[Sieur_Blabla]

??? Ah ouai!! Et comment tu ferais ça stp??
Je chechais aussi pour l'héritage, je trouve rien :p

[_skip]

Si tu passes le modèle de la combobox, ça devrait fonctionner. A ce qu'il me semble la combobox ne prendra pas l'ownership du modèle que tu lui passeras.

[Sieur_Blabla]

Oui, c'est justement ce que je n'ai pas compris; ce que tu veux dire par passer le modèle de la combox. :s

[gbdivers]

Il parle du modèle de la combobox... (oui, je sais. Je répète exactement ce qu'il a dit... mais on ne peut pas être plus explicite Tu devrais lire un peu la doc de QComboBox)

QComboBox uses the model/view framework for its popup list and to store its items. By default a QStandardItemModel stores the items and a QListView subclass displays the popuplist. You can access the model and view directly (with model() and view()), but QComboBox also provides functions to set and get item data (e.g., setItemData() and itemText()). You can also set a new model and view (with setModel() and setView()). For the text and icon in the combobox label, the data in the model that has the Qt:isplayRole and Qt:ecorationRole is used.

Pour le passage de paramètres dans une fonction, regarde la FAQ : http://cpp.developpez.com/faq/cpp/?p...sage_parametre

[Sieur_Blabla]

Merci pour vos réponses, mais j'opte pour l'héritage. La combobox n'est qu'un cas parmi d'autres où j'ai besoin d'utiliser les variables d'une classe dans une autre classe.

ce que je fais pour l'héritage multiple est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
class dialog_quench : public QDialog , private Ui::dialog_quench, virtual public data_edit
{
}

Or ce virtual public data_edit que j'ajoute à la fin me fait apparaitre 62 erreurs à la compilation, dont:
reference to 'setupUi' is ambiguous
reference to 'connect' is ambiguous
request for member 'close' is ambiguous

Ces erreurs se répètent plusieurs fois.
SVP, quelqu'un a-t-il une idée?

[_skip]

Le but de l'héritage n'est pas de casser l'encapsulation des classes. A mon avis tu fais complétement fausse route.

Si tu dois laisser accéder des membres d'une classe depuis l'extérieur, tu les rends simplement accessibles via des méthodes publiques avec prudence. Dans ton cas où c'est le code même de ta classe qui instancie l'objet enfant, fournir les infos nécessaires par le constructeur est tout indiqué.

Mais laisser les classes se trifouiller l'une l'autre sans une très bonne raison, ce n'est pas recommandable.
Enfin, je dis ça, je dis rien, c'est ton application.