wie gehen qobject als argument von signal-slot von qt verbinden

Mein original-code übergeben eine QStringList aus das signal an den slot und dann wieder eine QList. Alles funktionierte gut, aber ich brauchte, um zu ändern, sowohl die QStringList und QList in 2 unterschiedliche Unterklassen QObjects. Seitdem habe ich wurde empfangen Fehler wie "synthetisiert Methode zuerst hier" oder es einfach abstürzt, ohne Fehlermeldung.

Ich verstehe, dass qt kopiert alle übergebenen Argumente in eine Warteschlange Verbindung und ein qobject kann nicht kopiert werden. Also anstatt ein qobject ist, dachte ich, ich würde beide qobjects, die vor dem aussenden des Signals. Dann würde ich pass Referenzen auf jedes Objekt, ändern Sie Sie in den Steckplatz Funktion und void ist der Rückgabewert. Leider ist die app immer noch abstürzt, egal, wie ich code das signal-und slot-Funktionen. Wie kann ich code das signal/slot-Funktionen und verbinden Sie entweder pass qobjects, die als Argumente oder return ein 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&)));

Den receiveSignal () - Funktion nicht direkt erstellen oder ändern alle qobject. Es hat zum bestehen der qobjects, um eine andere Funktion, die ersten, die dann entweder ändert obj2 oder erstellt, und gibt es zurück. Alle code-Beispiele würde sehr geschätzt werden.

InformationsquelleAutor luxtor | 2013-08-02

  1. 11

    In der Regel QObject übergeben, indem Zeiger, die nicht durch Verweise (beachten Sie, dass QObject kann nicht kopiert werden und kann nicht durch Wert übergeben werden). QObject* ist registriert als meta-Typ standardmäßig aktiviert. So erstellen Sie ein signal und ein slot mit QObject* argument ist genug, um Ihnen Arbeit:

    private slots:
  void test_slot(QObject* object);

signals:
  void test_signal(QObject* object);

    Initialisierung:

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

    Ausstrahlen:

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

    Natürlich das signal und den slot konnte in verschiedenen Klassen.

    Sie brauchen nicht alle metatype-Registrierung für signal/slots, es sei denn, die Verbindung ist in Warteschlange. Und mit queued verbindungen sehe ich Eigentumsfragen mit object. Wem gehört es und löscht es wieder? Der emitter? Wann?
    QObject* ist eine generische metatype. Es ist standardmäßig eingetragen und wird von einigen built-in Signale (z.B. destroyed). In der Warteschlange verbindungen funktionieren auch ohne Registrierung. Eigentum von QObject wird deklariert, indem seine Eltern (es sei denn, es ist angelegt auf stack). Übergabe durch Zeiger in der Regel nicht dazu führen, dass das Eigentum problem und ist weit verbreitet in der Qt-API. In der Regel gibt es Konventionen in der API sagen, was passiert mit dem Eigentum, wenn eine Methode (slot) genannt wird.
    Metatype: ich weiß, das war nicht mein Punkt. Sie sagte, dass QObject* ist registriert als metatype, und es kann daher verwendet werden, in-Signals/slots. Es ist nicht obligatorisch, aber wenn Sie es war, die übergabe eines Arguments MyObjectSubclass* würde bereits scheitern, ohne sich zu registrieren MyObjectSubclass* als gut.
    Eigentum: Das problem ist, dass die Eltern/Kind-Eigentum wird Ihnen nicht helfen, mit signal/slots, insbesondere verbindungen in der Warteschlange. So erstellen QObjects dynamisch, nur um dann senden Sie diese über ein-signal ist nicht gängige Praxis, aus gutem Grund. Kann der Empfänger nicht das Objekt, denn es kann beliebig viele Empfänger-oder überhaupt keine. In den sender-Sie stapeln sich, wenn eine andere jedes mal erstellt, wenn test_signal() emittiert wird, es sei denn, der Absender löscht Sie sofort danach (aber dann ist der Zeiger würde baumeln, wenn verwendet, in der Warteschlange verbindet).
    Wenn Sie eine Verbindung in der Warteschlange, und der Empfänger kann über den Absender, dann kann es nicht löschen Sie die Objekte. Damit die Verwaltung der Objekte durch shared pointer und Weitergabe QSharedPointer<MyQObjectSubclass> vielleicht der beste Weg, in einigen Fällen. Oder einfach nicht mit signal/slots um das Problem zu lösen, sieht es hier falsch angewandt.

    InformationsquelleAutor Pavel Strakhov

Schreibe einen Kommentar