QObject::connect behaves different when using SLOTS() and SIGNALS() makro
-
Hi all,
i have a problem updgrading an application from Qt 6.2 to 6.7 (I also tried 6.5 there is the same error).
There is some weird code which creates a trigger on the stack and when the function closes it should emmit the trigger Signal when the function is done (Because of multiple return statements). Can someone tell me why it does not work anymore?
Does not work in 6.5 or 6.7 (Original from 6.2):
QAction close_notification_action("close_notification_action"); QObject::connect(&close_notification_action, &QAction::destroyed, &close_notification_action, &QAction::trigger, Qt::DirectConnection);The Problem is independent of Qt::DirectConnection or AutoConnection or anything like that.
Exits with QtPrivate::assertObjectType<QAction> :
Q_ASSERT_X(cast(o), Obj::staticMetaObject.className(), "Called object is not of the correct type (class destructor may have already run)");Works:
QAction close_notification_action("close_notification_action"); QObject::connect(&close_notification_action, SIGNAL(destroyed()), &close_notification_action, SLOT(trigger()));Somehow the destroyed Signal seems to be emmited at different moments?
Thanks for you help!
-
Hi all,
i have a problem updgrading an application from Qt 6.2 to 6.7 (I also tried 6.5 there is the same error).
There is some weird code which creates a trigger on the stack and when the function closes it should emmit the trigger Signal when the function is done (Because of multiple return statements). Can someone tell me why it does not work anymore?
Does not work in 6.5 or 6.7 (Original from 6.2):
QAction close_notification_action("close_notification_action"); QObject::connect(&close_notification_action, &QAction::destroyed, &close_notification_action, &QAction::trigger, Qt::DirectConnection);The Problem is independent of Qt::DirectConnection or AutoConnection or anything like that.
Exits with QtPrivate::assertObjectType<QAction> :
Q_ASSERT_X(cast(o), Obj::staticMetaObject.className(), "Called object is not of the correct type (class destructor may have already run)");Works:
QAction close_notification_action("close_notification_action"); QObject::connect(&close_notification_action, SIGNAL(destroyed()), &close_notification_action, SLOT(trigger()));Somehow the destroyed Signal seems to be emmited at different moments?
Thanks for you help!
The behavior is different in the time when the signal / slot connection is deleted. With pmf style it is done later (during QObject dtor) and therfore the assert.
Your connect does not do anything with the string based one and would likely crash when the assert would not be there. -
Hi all,
i have a problem updgrading an application from Qt 6.2 to 6.7 (I also tried 6.5 there is the same error).
There is some weird code which creates a trigger on the stack and when the function closes it should emmit the trigger Signal when the function is done (Because of multiple return statements). Can someone tell me why it does not work anymore?
Does not work in 6.5 or 6.7 (Original from 6.2):
QAction close_notification_action("close_notification_action"); QObject::connect(&close_notification_action, &QAction::destroyed, &close_notification_action, &QAction::trigger, Qt::DirectConnection);The Problem is independent of Qt::DirectConnection or AutoConnection or anything like that.
Exits with QtPrivate::assertObjectType<QAction> :
Q_ASSERT_X(cast(o), Obj::staticMetaObject.className(), "Called object is not of the correct type (class destructor may have already run)");Works:
QAction close_notification_action("close_notification_action"); QObject::connect(&close_notification_action, SIGNAL(destroyed()), &close_notification_action, SLOT(trigger()));Somehow the destroyed Signal seems to be emmited at different moments?
Thanks for you help!
@MaximilianM seems more like a fix than a regression in my opinion.
Doesn't make much sense that you would trigger a slot on an object that signalled the world that it was destroyed. Especially if the "Slot" just emits an other signal.
Have you tried connecting directly to the slot that QAction::triggered is connect to?
-
@MaximilianM seems more like a fix than a regression in my opinion.
Doesn't make much sense that you would trigger a slot on an object that signalled the world that it was destroyed. Especially if the "Slot" just emits an other signal.
Have you tried connecting directly to the slot that QAction::triggered is connect to?
@J-Hilk Your absolutly right that there are cleaner ways of programming this. This is somewhat older code and i dont want to touch it to much. But i definetly will think about changing it. Thanks for your opinion!
-
The behavior is different in the time when the signal / slot connection is deleted. With pmf style it is done later (during QObject dtor) and therfore the assert.
Your connect does not do anything with the string based one and would likely crash when the assert would not be there.@Christian-Ehrlicher So i checked that and it seems you are right. That the string based emit does nothing. That explains a lot. Thanks for you help!
-
M MaximilianM has marked this topic as solved on
