Discussion :

[stc074]

Bonjour, j'essaie de faire un menu QMenu, je veux lui ajouter a chaque action un objet de ma classe ActionMenu héritant de QACtion, dois-je redéfinir une methode de QACtion dans ActionMenu qui sera appelée en cas de sélection de l'item dans le menu ? si oui laquelle ?
Merci d'avance.

[LittleWhite]

Bonjour,

Vous pouvez utiliser le système de signal/slot pour appelé une fonction lorsqu'un élément du menu est sélectionné.
De mémoire, je n'ai jamais eu le besoin d'hérité de QAction, donc je suis un peu dubitatif sur la méthode que vous utilisez, mais soit.

[gbdivers]

Bonjour

Tu n'as pas besoin de créer une nouvelle classe pour cela. QAction fournit les fonctions data() et setData() pour attacher des données utilisateur dans une QAction (http://qt-project.org/doc/qt-5.0/qtw...n.html#setData)

[stc074]

Merci pour vos conseil je vais voir la doc.

[stc074]

Bonjour,

Vous pouvez utiliser le système de signal/slot pour appelé une fonction lorsqu'un élément du menu est sélectionné.
De mémoire, je n'ai jamais eu le besoin d'hérité de QAction, donc je suis un peu dubitatif sur la méthode que vous utilisez, mais soit.

Je ne comprends pas les slots, puis je mettre ma propre méthode, j'ai essayé :

Code :

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

connect(menus[i].action, SIGNAL(triggered()), this, SLOT(act()));

ça compile mais qtcreator me met une erreur dans la console :

Code :

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

Object::connect: No such slot QMenuBar::act()

Merci.

[koala01]

Salut,

La connexion ne devrait pas se faire au niveau de la barre de menu, mais plutôt au niveau du formulaire qui expose le slot "act" (selon ton exemple).

Ceci dit:

Bonjour,

Vous pouvez utiliser le système de signal/slot pour appelé une fonction lorsqu'un élément du menu est sélectionné.
De mémoire, je n'ai jamais eu le besoin d'hérité de QAction, donc je suis un peu dubitatif sur la méthode que vous utilisez, mais soit.

Hé bien, il m'est déjà arrivé de trouver qu'il était plus facile de dériver une action personnelle de QAction que de commencer à connecter une action de manière systématique à différents items.

Ce sont, bien sur, des cas particuliers, mais, si tu as une action qui doit être partagée entre différents formulaires, bien qu'elle appelle toujours la même méthode (tout à fait globale), et que tu dois, en plus, décider de l'activer ou non (voire décider de l'afficher dans le menu ou non) ou encore l'avoir dans le menu et/ou dans le menu contextuel, de différents formulaires, cela peut apporter une certaine facilité, surtout si tu appliques "à la lettre" le principe du MVC

Pour faire comprendre le principe (je l'ai dit: c'est un cas particulier, hein ):

Mettons que tu manipules un grand nombre de données métier de types différents, tous plus ou moins mises en relation les uns avec les autres, dans une application "multi document".

Pour chaque type de donnée (ou peu s'en faut), tu as créé différents types de vues (mettons, une "simple" vue tabulaire et une vue basée sur QGaphicsView et ses acolytes).

Chaque type de donnée n'est modifiable que sous certaines conditions, mais tu peux agir aussi bien depuis la vue "graphique" que depuis la vue "tabulaire".

Bien sur, les différentes actions que tu peux effectuer sur un type de donnée particulier présente leur propre texte et sont disponibles sous différentes formes (bouton, menu général, menu contextuel, pourquoi pas double clique, ...)

La "meilleure solution" consiste à faire en sorte que les différentes vue d'un même type partagent un même modèle de sélection, de manière à ce que, si tu sélectionne un item particulier dans une vue particulière, la sélection soit automatiquement "reportée" vers toutes les vues actives que tu peux avoir de cet item, puis d'activer (ou non) et d'afficher (ou non) les actions en fonction du contexte particulier.

De cette manière, chaque action appelle une fonction qui ne doit être codée qu'une fois, basée sur les items sélectionnés (au niveau du modèle de sélection propre au type de donnée particulier sur lequel tu travailles) et accessible (ou non) en fonction du contexte de la vue sur laquelle tu travailles.

"Tout ce qu'il te reste à faire", c'est de veiller pour chaque vue à afficher (ou non) et à activer (ou non) les différentes actions que tu as envisagées

Le fait de dériver de QAction te permet de placer le code de cette action qui ne doit être implémenter qu'une seule fois directement... au niveau de ta classe dérivée de QAction.

Cela te permet, entre autres, d'éviter les "dépendances ascendantes" par lesquelles un sous sous sous formulaire en vient à dépendre explicitement du formulaire de base