J'ai essentiellement des signaux d'événements multiples que je veux me connecter au même emplacement. Ce que je veux savoir, c'est ainsi que puis-je passer des paramètres à la chaîne sur cette même fente afin que la fente sache quel est ce signal provenant de. Une alternative consiste à apporter autant de créneaux sous forme de signaux, puis à les connecter de manière 1: 1, mais cela est efficace, en considérant que le code de tout le traitement est très similaire. J'ai essayé de le faire, mais je reçois des erreurs: L'erreur est liée aux paramètres que je passe dans les 2 dernières commandes .. et peut-il me dire quelle erreur est dans le code ci-dessus? fond de point de fond est déclaré comme ceci:
6 Réponses :
Vous ne pouvez pas passer des constantes à Cependant, alors que cela est contre le Exemple ci-dessous: Si vous avez de nombreux boutons, vous pouvez également utiliser un Qsignalmapper en fournissant un identifiant pour chaque bouton. Connect () car les paramètres effectifs sont déduits au moment de l'exécution, pas de compilation de temps. OO Principe, vous pouvez utiliser QOBJECT :: Sender () qui donne un pointeur à l'émetteur qObject .
On pourrait également utiliser la propriété ObjectName: doc.trolltech.com/4.5/qObject .html # ObjectName-Prop
Vous pouvez utiliser QsignalMapper . Bien que le Qsignalmapper soit la réponse à votre question, je pense que la réponse de Jon Hanson est la façon dont vous devriez prendre. Vous obtenez beaucoup plus de code plus propre de cette façon.
Je pense que dans ce cas qsignalmapper est la voie à suivre. Imaginez des boutons changeants sur qcombobox ou tout autre changement d'assurance-chômage. Avec Qsignalmapper, changement trivial dans un fichier .cpp. Avec des emplacements séparés, changement de signature de classe nécessaire.
Qu'est-ce qui est inefficace sur l'utilisation de machines à sous séparées? S'il y a des points de communication dans les gestionnaires de machines à sous, déplacez-le dans une fonction, par exemple. Extension de l'exemple d'Ereon:
Imaginez si l'interface utilisateur doit être modifiée de manière arbitraire et comparez les modifications nécessaires du code avec cette approche et QsignalMapper approche.
Et si votre UI change au moment de l'exécution? Pas de moyen, José.
quatre méthodes. On ne suce pas.
Qsignalmapper code>. Fonctionne, mais fait du code désordonné. Li>
- Slots nommés. Messy pour tout nombre important d'expéditeurs et ne fonctionne pas pour des expéditeurs générés par dynamisme (par exemple, des boutons dans une liste). LI>
-
expéditeur () code> -compare. Peut gérer des expéditeurs dynamiques, mais reste un peu laid. Li>
- Sous-classe L'expéditeur strong>. Ne suce pas. Vous donne ce que vous vouliez vraiment tous: signaux paramétrés em>. Li>
OL>
Surtout lorsque vous utilisez un petit nombre de signaux et de types d'expéditeurs et lorsque les expéditeurs sont générés de manière dynamique, la sous-classement de l'expéditeur est le moyen le plus propre. Cela vous permet de surcharger les signaux existants pour contenir les paramètres dont vous avez besoin. P>
et maintenant, câblant les signaux et les fentes fonctionne simplement: P> Keypad::Keypad(QWidget *parent) : QWidget(parent)
{
for (int i = 0; i < 10; ++i)
{
// KeypadButton keeps track of the identifier you give it
buttons[i] = new KeypadButton(i, this);
// And passes it as a signal parameter. Booyah.
connect(buttons[i], SIGNAL(clicked(int)), this, SIGNAL(digitClicked(int)));
}
createLayout();
}
void Keypad::digitClicked(int digit)
{
// The slot can find the clicked button with ease:
dial(button[i]); // or whatever
//...
}
Je pense que vous devriez éviter QsignalMapper chaque fois que vous pouvez (raisonnablement). Les meilleures solutions (qui mènent au code de nettoyage) sont les suivantes: 1) Sous-classe et envoyez votre identifiant souhaité dans le signal comme @Foamy écrit. Nous utilisons cela dans notre projet QT chaque fois que nous le pouvons (mais ce n'est pas une bonne idée de la sous-classe juste pour le faire) et 2) obtenir l'expéditeur () dans votre emplacement, Typecheck IT et comparer avec tout identifiant / balise que vous voulez et l'expéditeur a.
@Viktorbenei Je suis d'accord, sauf que je pense que cela vaut la peine de sous-classer uniquement pour des signaux paramétrés. C'est un peu plus de travail dans la sous-classement, mais conserve le reste de votre code dont beaucoup plus propre.
Si vous ne voulez vraiment pas utiliser QsignalMapper, vous pouvez faire quelque chose comme ceci: mais QSignalMapper est tout aussi facile ... P> QSignalMapper *mapper = new QSignalMapper(this);
connect(button1, SIGNAL(clicked()), mapper, SLOT(map()));
mapper->setMapping(button1, "button 1");
connect(button2, SIGNAL(clicked()), mapper, SLOT(map()));
mapper->setMapping(button2, "button 2");
// you might have to tweak the argument type for your slot...
connect(mapper, SIGNAL(mapped(const QString &), this, SLOT(backgroundTypeChoiceMade(QString)));
Vous pouvez maintenant vraiment lier une valeur lors de la connexion. QT5 a ajouté une prise en charge ajoutée pour cela. Exemple: voir Plus d'infos . NB: Vous pouvez bien sûr utiliser STD :: Bind ou Boost :: Linez au lieu de TR1 :: Bind.