Seite 1 von 1
Hat Qt eine Art Signalbuffer?
Verfasst: 25. Juni 2010 10:05
von Neuling_
Hallo,
ich wollte mal fragen ob jemand weiß, ob Qt eine Art Signalbuffer hat;
soll heißen:
signal1 -> foo1()
signal2 -> foo2()
signal3 -> foo3()
signal4 -> ...
signal5 ....
...
Wenn das erste Signal ermittelt wurde wird foo1 aufgerufen, während
foo1 ausgeführt wird treten aber neue signale auf (bsp.: signal2,3,4)
- Wird nun automatisch nach foo1(), foo2() aufgerufen?
- Oder wird foo2() sofort aufgerufen auch wenn Programm gerade foo1() ausführt?
Mein Problem ist momentan schätzungsweise, dass ein SLOT1 ausgeführt wird während neue Signale eintreffen.
Nachdem mein SLOT1 durchlaufen ist sind die zwischenzeitlich eingetretenen Signale aber ungültig und die entsprechenden SLOT's sollen nicht mehr ausgeführt werden.
Wäre toll wenn mir jemand den funktionalen Ablauf erklären könnte.
Grüße
Verfasst: 25. Juni 2010 10:27
von franzf
Leider bin ich mir nicht ganz im Klaren darüber, was du eigentlich willst.
Drum erstmal der Hinweis in Richtung "Qt::ConnectionType", welches du beim connect() angeben kannst.
Dich interessieren "QueuedConnection" und "DirectConnection".
Vielleicht kannst du deine Frage damit selber beantworten.
Verfasst: 25. Juni 2010 12:09
von RHBaum
Wenn das erste Signal ermittelt wurde wird foo1 aufgerufen, während
foo1 ausgeführt wird treten aber neue signale auf (bsp.: signal2,3,4)
definitiv multithreaded umgebung, sonst koennte das nie passieren !
Wird nun automatisch nach foo1(), foo2() aufgerufen?
kommt drauf an, wie connected wurde, also in welcher eventloop die connections laufen.
Nehmen wir an, foo1..x laufen in der selben eventloop, und damit alle im selben thread, wird nacheinander abgearbeitet ja.
ich wollte mal fragen ob jemand weiß, ob Qt eine Art Signalbuffer hat;
das kannst dir nu fast selber beantworten !
Signale ueber threads hinweg verwenden Eventloops. dein buffer iss also die eventloop !
Ciao ....
Verfasst: 25. Juni 2010 13:05
von Neuling_
OKey, danke für die Infos.
Code: Alles auswählen
class A : QLabel
{
signal1;
signal2;
signal3;
...
}
class B : QThread
{
A* ClassAInstanz;
connect(ClassAInstanz, SIGNAL(signal1), this, SLOT(slot1));
connect(ClassAInstanz, SIGNAL(signal2), this, SLOT(slot2));
slot1();
slot2();
}
So stand es bisher geschrieben wobei der Qt::ConectionType dann auf Qt::DirectConnection gesetzt wird oder?
Code: Alles auswählen
Qt::AutoConnection: (default) Same as DirectConnection, if the emitter and receiver are in the same thread. Same as QueuedConnection, if the emitter and receiver are in different threads.
Dann liegt mein Fehler wohl wo anderst.
Ich denke, dass ein anderer Thread meines Programmes auf die Instanz von Klasse B zugreifen will und dies in einem Moment in dem ich die Instanz veränderer. (Obwohl ich das eigentlich abfrage -> verhindere)
Ich würde ja gerne Code posten, aber das Program erstreckt sich über mehrere tausend zeilen Code :/
...bin mal weitersuchen
PS: Ich reagiere auf die MouseMove, MouseBtnPressed, MouseBtnReleased-Events.
kann ich aus dem MouseBtnReleaseEvent heraus für eine bestimmte Zeit das MouseMoveEvent blockieren?
Verfasst: 25. Juni 2010 13:54
von RHBaum
kann ich aus dem MouseBtnReleaseEvent heraus für eine bestimmte Zeit das MouseMoveEvent blockieren?
Die frage stellt sich eigentlich gar ned !
Die Events vom BS, also von der GUI laufen alle im Mainthread. GUI operationen ausserhalb des mainthreads sind verboten !
das heisst, die events kommen, aber werden in der Queue abgelegt.
und du bekommst im mainthread nacheinander die Eventhandler gefeuert. DU bekommst also definitiv alles schoen nacheinander, wenn du nicht selber assynchron reagierst, also einfach selber nen threadwechsel machst.
Bessser waer, beim MouseBtnReleaseEvent ne statusvariable setzen, welche im Handler der Mousemoveevents die funktionalitaet ein bzw. ausschaltet, wenn du wirklich sowas brauchst ...
Ciao ...