Héritage de signaux : redéfinition possible ?

Version imprimable

29/06/2010, 11h51
L-F-an

Héritage de signaux : redéfinition possible ?

Bonjour,

Je voudrais savoir si il est possible de surcharger/redéfinir un signal dans une classe fille.

Je m'explique :
Dans la classe QMenu, j'ai le signal hovered(QAction*) qui m'intéresse.
Cependant j'ai fait une classe dérivée de QAction pour y ajouter des attributs et quelques fonctions.
J'ai appelé cette classe SousMenu.

Est-il possible d'avoir un signal du type hovered(SousMenu*) éventuellement en dérivant aussi la classe QMenu?
29/06/2010, 14h04
Gulish

Si ta classe SousMenu dérive de QAction, ça veut dire que ta classe SousMenu a toutes les propriétés de QAction + celles que tu as ajouté.

Donc tu n'as rien à modifier, le signal marchera tout seul.

TU peux faire

Code:

monMenu.addAction(new SousMenu(blabla));

ça marchera aussi.

G.
29/06/2010, 14h24
L-F-an

Hello,
Merci de répondre.
Je fais bien comme tu as dis pour ajouter mon sous menu au menu.
Seulement ensuite je voudrais connecter le clic et le survol souris de mes SousMenus à des slots.

Logiquement, cette connexion se fait comme ça : (pour le survol)

Code:

connect(un_Menu,SIGNAL(hovered(QAction*)),this,SLOT(cliqueSousMenu(QAction*)));

Mais là le signal dépend de un_Menu.
Je cherche à passer en paramètres mon SousMenu dans le connect comme ceci :

Code:

connect(un_Menu,SIGNAL(hovered(SousMenu*)),this,SLOT(cliqueSousMenu(SousMenu*)));

Je cale un petit peu.
J'ai voulu dériver la classe QMenu et surcharcher le signal "hovered" mais je ne sais pas trop comment m'y prendre... :?

Si tu as déjà fait ça...
29/06/2010, 16h31
haraelendil

Tu n'as pas besoin de surcharger le signal, soit ton sous menu hérite de QMenu, et il va faire les choses comme le ferai un menu normal (donc tu connecte ton signal de la même façon), sinon tu crée une classe de toute pièce, et la c'est à toi de faire des emit(monSignal) quand tu veux que ton sous menu émette ce signal...

Alors comment retourner un attribut de mon SousMenu depuis le slot cliqueSousMenu() ?
Je vous mets une partie de ma classe SousMenu :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 class SousMenu: public QAction { public: SousMenu(QString nom, QObject *parent):QAction(nom,parent=0){ } //Accès aux attributs du SousMenu void setMotCle(QString motCle); QString getMotCle(); private: QString m_MotCle; };
et le slot cliqueSousMenu()
Code:

1 2 3 4 5 6 7 void FenetrePrincipale::cliqueSousMenu(SousMenu* sMenu){ //Affichage du mot clé de sous menu dans un QTextBrowser //sur la fenêtre principale. this->visu->append(sMenu->getMotCle()); }
Si le slot cliqueSousMenu n'a pas un SousMenu en paramètre, il ne peut me retourner l'attribut m_MotCle.

Si c'est ton sousMenu qui émet le signal directement, tu peux récupérer un pointeur sur celui-ci grâce à QObject::sender()
Code:

1 2 3 4 5 6 7 8 void FenetrePrincipale::cliqueSousMenu() { //Affichage du mot clé de sous menu dans un QTextBrowser //sur la fenêtre principale. SousMenu* sMenu = qobject_cast<SousMenu*>(sender()); if(sMenu == NULL) return; this->visu->append(sMenu->getMotCle()); }

Oui ça j'avais vu.
A la rigueur je peux faire envoyer le signal par le SousMenu et le caster ensuite même si ce n'est pas ce que je veux faire à la base.
Donc pour répondre à la question du début on ne peut pas surcharger un signal.

Et comme tu peux le voir, je ne mets pas le QOBJECT dans ma classe, je ne comprends pas trop son utilisation.
Pour utiliser l'option que tu proposes je suis obligé de le faire.

Quelles sont les différences avec ma classe d'origine si je rajoute ça?
Code:

1 2 3 4 5 6 7 8 9 10 11 class SousMenu: public QAction { Q_OBJECT // ajout ici par rapport à la classe d'origine // Seule modification à effectuer? public: SousMenu(QString nom, QObject *parent):QAction(nom,parent=0){ } ... };

29/06/2010, 17h44
haraelendil

La macro Q_OBJECT est nécessaire si tu veux te servir des signaux / slots de ta classe, ainsi que les propriétés des QObjects

plus d'info sur cette macro:
article sur les méta-objets

Bonjour à tous

J'ai un peu de mal à comprendre... 8O

1. QMenu hérite de QWidget et représente un objet visible à l'écran. QAction par contre hérite directement de QObject et n'est pas sensé représenter un objet visible (et donc pas un sous menu en particulier). Donc pour créer un sous menu, tu dois hériter de QMenu et non de QAction

2. Si tu veux créer un sous menu, tu peux simplement utiliser addMenu de QMenu :
Code:

1 2 3 4 5 6 7 8 9 10 QMenu * menu = new QMenu("mon menu"); m->addAction(new QAction("action 1", menu); m->addAction(new QAction("action 2", menu); m->addAction(new QAction("action 3", menu); m->addAction(new QAction("action 4", menu); QMenu * sous_menu = new QMenu("mon sous menu"); menu->addMenu(sous_menu); sous_menu->addAction(new QAction("sous menu 1", sous_menu)); sous_menu->addAction(new QAction("sous menu 2", sous_menu)); sous_menu->addAction(new QAction("sous menu 3", sous_menu));
3. Comme indiqué dans la doc de QObject ("Warning: This function violates the object-oriented principle of modularity."), sender() ne respecte pas la conception objet et doit être évité (son utilisation indique en général un problème de conception)

As tu une raison particulière de vouloir hériter de QAction pour ton sous menu (c'est à dire quels sont les caractéristiques de QAction que tu souhaites utiliser/hériter et quels sont celles que tu souhaites ajouter/modifier) ?

29/06/2010, 17h53
L-F-an

Merci beaucoup !
J'ai cherché un article qui expliquait ça mais j'avais pas trouvé :aie:
Je vais regarder ça tranquillement ce soir et si ça me convient je mettrai résolu.
:ccool:merci encore.
29/06/2010, 18h05
L-F-an

Salut gbdivers,

Lors de mon clic souris sur un sousmenu (donc un QAction), je veux récupérer un motClé qui va conditionner tout l'affichage de ma fenêtre ensuite.

Pour moi, le QMenu est le "conteneur" dans lequel on ajoute des "sousMenus" sur lesquels on peut agir.
Il y a un mot clé par sousMenu c'est pour ça que je veux dériver un QAction.
Comme exemple la barre de la fenêtre : Dans le menu Fichier on trouve les QAction "Nouvelle fenêtre", "Nouvel Onglet", "Ouvrir une fenêtre..." ...

Enfin c'est possible que je l'utilise completement de travers aussi :oops:

Ok, je comprend mieux.

Le menu est bien le conteneur (un QMenu dans Qt) qui contient des items (des QAction dans Qt) et pas un sous-menu. Un sous menu, c'est un menu (donc un QMenu) contenu dans un menu (par exemple un liste de fichiers récents)
C'est bien des QAction que tu veux utiliser.

Donc, la question suivante était pourquoi créer une classe héritant de QAction ?
A priori, tes QAction font juste leurs boulots : émettre un signal quand on clique dessus. Donc tu utilises le comportement par défaut des QAction et tu n'as pas besoin de créer une classe enfant.

Normalement, tu dois simplement créer un slot par QAction et les connecter ensemble :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 // lors de la création des menus QMenu * menu = new QMenu("Mon menu"); QAction * etat1 = new QAction("Passer la fenêtre dans l'état 1", menu); menu->addAction(etat1); connect(etat1, SIGNAL(triggered()), this, SLOT(doEtat1())); // ton slot pour ton état 1 void MainWindow::doEtat1() { // tu modifies l'affichage de ta fenêtre en donnant le mot clé correspondant modifierAffichageDeTaFenetre("mot clé état 1"); } // idem pour chaque état possible
Autre possibilité (si tu as beaucoup d'états possible ou si le nombre d'états est dynamique), tu récupères le triggered(QAction*) du QMenu :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 // lors de la création des menus QMenu * menu = new QMenu("Mon menu"); menu->addAction(new QAction("Passer la fenêtre dans l'état 1", menu)); connect(menu, SIGNAL(triggered(QAction*)), this, SLOT(doEtat(QAction*))); // ton slot pour tous tes états void MainWindow::doEtat(QAction * action) { // tu récupères le texte du QAction puis tu testes les différentes possibilités QString str = action->text(); if(str == "Passer la fenêtre dans l'état 1") modifierAffichageDeTaFenetre("mot clé état 1"); else if( ... }

30/06/2010, 06h19
L-F-an

Je vois ce que tu veux faire. Ca impliquerait que je connaisse toutes les possibilités de motCle et des menus.
Seulement mon menu ainsi que les motCle sont totalement inconnus avant le lancement de l'appli.
Je les charge depuis un fichier XML modifiable, c'est pour cette raison que je dérive un QAction, pour lui rajouter l'attribut motCle.
Quand je parcours le XML, je créé tous mes objets QAction dérivés en leur ajoutant l'attribut motCle.
30/06/2010, 09h16
yan

Citation:

Envoyé par gbdivers

Autre possibilité (si tu as beaucoup d'états possible ou si le nombre d'états est dynamique),

Ou tu utilise un QSignalMapper. C'est fait pour cela ;)

Après ça dépend du besoin. Le problème en récupérant le text de QAction est dans le cas de l'utilisation de traduction. Va savoir ce que sera le text.

Ou tu utilise un QSignalMapper... :)
J'ai pensé après que je n'avais pas signalé cette possibilité.

Pour la traduction, tu as raison. Ça ne serait pas très "propre". Il faudrait dans cette solution utiliser les propriétés des QObject pour ajouter une propriété "keyword" par exemple.

Avec QSignalMapper :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// lors de la création des menus
QSignalMapper * mapper = new QSignalMapper(this);
QMenu * menu = new QMenu("Mon menu");
for ( /* pour chaque élément du xml */ )
{
   QAction * action = new QAction(menu);
   action->setText( /* le QString du menu récupéré dans le xml */ );
   connect(action, SIGNAL(triggered()), mapper, SLOT(map()));
   mapper->setMapping(action, /* le mot clé récupéré du xml */ );
   menu->addAction(action);
}
connect(mapper, SIGNAL(mapped(const QString &)), this, SLOT(doEtat(const QString &)));
 
 
 
// ton slot pour tous tes états
void MainWindow::doEtat(const QString & str)
{
    te->append( str );
}

Sans QSignalMapper :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// lors de la création des menus
QMenu * menu = new QMenu("Mon menu");
for ( /* pour chaque élément du xml */ )
{
   QAction * action = new QAction(menu);
   action->setText( /* le QString du menu récupéré dans le xml */ );
   action->setProperty("keyword", QVariant( /* le mot clé récupéré du xml */ ));
   menu->addAction(action);
}
connect(menu, SIGNAL(triggered(QAction*)), this, SLOT(doEtat(QAction*)));
 
 
 
// ton slot pour tous tes états
void MainWindow::doEtat(QAction * action)
{
   // tu récupères le mot clé du QAction puis tu le transmets
   if(action->property("keyword").isValid())
      modifierAffichageDeTaFenetre( action->property("keyword").toString() );
}

Dans tous les cas, créer une classe héritant de QAction, même si c'est possible, n'est pas le plus simple dans ce cas (et appeler un item "sous menu" n'est pas vraiment judicieux)

J'espère que ça t'aide un peu.

30/06/2010, 11h44
yan

Citation:

Envoyé par gbdivers

Pour la traduction, tu as raison. Ça ne serait pas très "propre". Il faudrait dans cette solution utiliser les propriétés des QObject pour ajouter une propriété "keyword" par exemple.

:king:
30/06/2010, 23h37
L-F-an

Merci beaucoup tout le monde, j'ai appris plein de choses.
Vous êtes au top ! :ccool:
08/07/2010, 09h49
ness522

J'ai déjà utilisé QActionGroup et
void QAction::setData ( const QVariant & userData )
pour setter le keyword

ensuite un seul signal, QActionGroup.triggered() permet de récupérer le keyword de l'action cliquée...