comment passer de qobject, comme argument à partir du signal de slot qt connecter

Mon code d'origine a adopté une QStringList à partir du signal de la fente, et est ensuite retourné une QList. Tout a bien fonctionné mais j'avais besoin de changer à la fois la QStringList et QList dans 2 différents sous-classé QObjects. Depuis lors, j'ai été de recevoir des erreurs comme "synthétisé méthode exige d'abord ici" ou il se bloque tout simplement sans aucun message d'erreur.

Je comprends que qt copies de tous les arguments passés dans une file d'attente de connexion et un qobject ne peuvent pas être copiés. Donc, au lieu de retourner un qobject, j'ai pensé que je voudrais créer à la fois qobjects avant d'émettre le signal. Alors je voudrais passer des références pour chaque objet, de modifier l'un d'eux dans le logement de fonction et l'annulation de la valeur de retour. Malheureusement, l'application se bloque toujours, peu importe comment je code le signal et le slot fonctions. Comment puis-je code le signal/slot fonctions et de les connecter à passer soit à la fois qobjects comme arguments ou de restitution d'un qobject?

MyQObject1 obj1("a","b","c");
MyQObject2 obj2();
emit sendSignal(&obj1, &obj2);
//or
MyQObject2 obj2 = emit sendSignal(&obj1);

connect(someObj, SIGNAL(sendSignal(const QObject&)), this, SLOT(receiveSignal(const QObject&)));

La receiveSignal() la fonction n'est pas directement créer ou modifier des qobject. Il doit passer la qobjects à une autre fonction première qui soit modifie obj2 ou crée et retourne. Tous les exemples de code serait grandement apprécié.

OriginalL'auteur luxtor | 2013-08-02

  1. 11

    Généralement QObject est passé par pointeur, et non par référence (à noter que QObject ne peuvent pas être copiés et ne peuvent pas être passés par valeur). QObject* est enregistré en tant que méta-type par défaut. Création d'un signal et un slot avec QObject* argument est suffisant pour leur travail:

    private slots:
  void test_slot(QObject* object);

signals:
  void test_signal(QObject* object);

    Initialisation:

    connect(this, SIGNAL(test_signal(QObject*)), this, SLOT(test_slot(QObject*)));

    Émettant:

    QObject* object = new QObject();
emit test_signal(object);

    Bien sûr, le signal et l'emplacement pourrait être dans des classes différentes.

    Vous n'avez pas besoin de tout metatype enregistrement de signaux/slots, sauf si la connexion est attente. Et avec en file d'attente de connexions je vois les questions de propriété avec object. Qui en est le propriétaire et le supprimer à nouveau? L'émetteur? Quand?
    QObject* est un générique metatype. Il est enregistré par défaut et utilisé par certains intégrée de signaux (par exemple destroyed). File d'attente de connexions de travail ainsi sans inscription. La propriété de QObject est déclarée par l'établissement de ses parents (sauf si il est créé sur la pile). Le passage par pointeur généralement ne provoque pas de propriété problème et il est largement utilisé dans l'intervalle Qt de l'API. Il y a généralement des conventions de l'API de raconter ce qui se passe avec la propriété lorsqu'une méthode (slot) est appelée.
    Metatype: je sais que, ce n'était pas mon point. Vous avez dit que QObject* est enregistré comme metatype, et il peut donc être utilisé dans de signaux/slots. Il n'est pas obligatoire, si elle a été, en passant par un argument de MyObjectSubclass* serait déjà en panne sans inscription MyObjectSubclass*.
    La propriété: le problème, c'est que le parent/enfant, la propriété ne sera pas vous aider avec des signaux/slots, en particulier en file d'attente de connexions. Ainsi, la création de QObjects dynamiquement juste pour ensuite les envoyer par l'intermédiaire d'un signal n'est pas de pratique courante, pour une bonne raison. Le récepteur ne peut pas posséder l'objet, car il peut être arbitraire beaucoup de récepteurs ou pas du tout. L'adresse de l'expéditeur ils seront pile si un autre est créé à chaque fois test_signal() est émis, à moins que l'expéditeur ne les supprime immédiatement par la suite (mais alors le pointeur serait dangle quand utilisé dans la file d'attente se connecte).
    Si vous êtes en utilisant une file d'attente de connexion, et les récepteurs peuvent survivre à l'expéditeur, il ne peut pas supprimer des objets. Ainsi, la gestion des objets par pointeur partagé et en passant QSharedPointer<MyQObjectSubclass> peut-être le meilleur moyen de sortir dans certains cas. Ou tout simplement ne pas utiliser de signaux/slots pour résoudre le problème, il semble mal appliqué ici.

    OriginalL'auteur Pavel Strakhov