Non-GUI thread

[foxyproxy]

Hello; I'm writing a Gui that use lib callbacks where I have no control of them. I have created a class that inherits from QWidget and

library listener so when something happens, this function is called by the library:

class MyClass : public QWidget, public LibraryListener
{
	MyClass(QWidget *parent = 0) : QWidget(parent)
	{
		Library::getIstance()->addListener(this); // add the listener
	}
}
 
void MyClass::on(Listener::listener, Object *o)
{
	emit signal(o);
}

class MyClass : public QWidget, public LibraryListener
{
	MyClass(QWidget *parent = 0) : QWidget(parent)
	{
		Library::getIstance()->addListener(this); // add the listener
	}
}

void MyClass::on(Listener::listener, Object *o)
{
	emit signal(o);
}

To copy to clipboard, switch view to plain text mode 

Library lives in own thread and it usually starts others. I know Qt complains if the sender's and receiver's thread ae different. Infact

application is killed with the following error:

ASSERT failure in QCoreApplication::sendEvent: "Cannot send events to objects owned by a different thread. Current thread 2aaaac07be40.

Receiver 'updateButton' (of type 'QPushButton') was created in thread 6a9db0", file kernel/qcoreapplication.cpp, line 274

It usually works and it usually don't. Why doesn't this problem happen always?

I think I should create a new class that inherits from QThread and this class through queued signals handles lib thread. Am I wrong?

Thank your your answer

[wysota]

You have to provide more code or better yet present a minimal compilable example reproducing the problem.

[foxyproxy]

Thank you so much for your quick answer
Sorry wysota, I think it crashed because I did this:

emit slot(o);

emit slot(o);

To copy to clipboard, switch view to plain text mode 

I used a slot instead of signal!

Last question: do u think that is the right approach emitting signal when client callback is called or is it better to handle it with QThread?

Thank you sir

[wysota]

You can emit signals wherever you see fit.