How can I pass an object of type QSharedPointer<QObjectDerivedClass> to QML?
If I do something like that
Q_PROPERTY(QObject* object READ object NOTIFY objectChanged)
public:
QObject* object() { return m_object.data(); }
void setObject(const QSharedPointer<QObjectDerivedClass>& object) { m_object = object; emit objectChanged(); }
signals:
void objectChanged();
private:
QSharedPointer<QObjectDerivedClass> m_object;
it works, but when I change the object with setObject() QML crashes randomly because the pointer holded by m_object is destroyed.
How can I fix it?
Related
I have a QVector of pointers to type X, whose items, i.e. X's own QProcesses. These processes can terminate at arbitrary time. Now, I have constructed signal-slot connection inside class X when a process ends. However, I want to propagate it to the handler class which has a QVector of X* as a member. What is an elegant way for doing this?
You can connect a signal to a signal, hiding the source signal being an implementation detail:
class MyInterface : public QObject {
Q_OBJECT
...
QProcess m_process;
public:
Q_SIGNAL void processEnded();
MyInterface(QObject * parent = 0) : QObject(parent) {
connect(&QProcess, &QProcess::finished, this, &MyInterface::processEnded);
...
}
};
The handler class can listen to these signals and do something with them.
class Handler : public QObject {
Q_OBJECT
QVector<MyInterface*> m_ifaces; // owned by QObject, not by the vector
void addInterface(MyInterface* ifc) {
ifc->setParent(this);
connect(ifc, &MyInterface::processEnded, this, [this, ifc]{
processEnded(ifc);
});
m_ifaces.append(ifc);
}
void processEnded(MyInterface* ifc) {
// handle the ending of a process
...
}
...
};
I have the following class, set in a ContextProperty at the start of the application:
class MyClass : public QObject
{
Q_OBJECT
public:
Q_INVOKABLE MyClassModel getModel() const { return m_myClassModel; }
private:
MyClassModel m_myClassModel;
}
In one of its methods, MyClass fills m_myClassModel with data (coming from a server).
MyClassModel also inherits QObject (because of Q_PROPERTY macros):
class MyClassModel : public QObject
{
Q_OBJECT
// Lots of Q_PROPERTY macros
Q_PROPERTY(int stuff READ stuff WRITE setStuff NOTIFY stuffChanged)
public:
...
signals:
void stuffChanged();
...
}
Then, in a QML file, MyClassModel is used to trigger signals and update graphical elements:
Item
{
anchors.fill: parent
CustomLabel
{
Connections
{
target: myClass.myClassModel()
onStuffChanged: { console.log("signal triggered!") }
}
}
}
Because of Q_INVOKABLE MyClassModel getModel() const { return m_myClassModel; }, I'm getting this error:
error: C2248: 'QObject::QObject' : cannot access private member declared in class 'QObject'
I think I understand the cause of this error, but I am not sure about what I should do to prevent it. I need to have access to MyClassModel from MyClass in order to fill it with data, yet I cannot return it into my QML file.
You are returning MyClassModel from getModel. This means copying the object. Copying MyClassModel involves a call to the implicitly generated copy constructor, which in turn calls copy constructor of base class (QObject). But copy constructor of QObject is private, this is why you get an error. Designers of Qt have decided long time ago that QObject should be non-copyable.
Solution is to return a pointer:
Q_INVOKABLE MyClassModel* getModel() const { return &m_myClassModel; }
I am using RtMidi library to handle midi message in my Qt application and I am facing problem with slot trigger:
My PhMidiInput object is emiting signal from the RtMidi callback upon specific midi message but the slots are not always triggered.
Here is a part of the PhMidiInput class:
class PhMidiInput : QObject
{
Q_OBJECT
public:
void PhMidiInput() {}
signals:
void quarterFrame(unsigned char data);
private:
static void callback(double, std::vector< unsigned char > *message, void *userData ) {
PhMidiInput *midiInput = (PhMidiInput*)userData;
if(midiInput)
midiInput->onMessage(message);
}
void onMessage(std::vector<unsigned char> *message) {
...
emit quarterFrame(data);
...
}
}
Connecting to a lambda functor works:
PhMidiInput midiIn;
int quarterFrameCount;
connect(&midiIn, &PhMidiInput::quarterFrame, [&](unsigned char data) {
quarterFrameCount++;
});
Connecting to my application window works to:
// MyWindow inherits from QMainWindow
connect(_midiIn, &PhMidiInput::quarterFrame, this, &MyWindow::onQuarterFrame);
When trying to connect to a custom class (MidiTest) inheriting from QObject it does'nt trigger:
connect(_midiIn, &PhMidiInput::quarterFrame, this, &MidiTest::onQuarterFrame);
I was wondering if there was something around QObject::moveToThread() but since I don't create the thread myself (the signal is sent from a callback) I don't know if I need to use it or not.
It is as simple as calling emit obj->quarterFrame(data); from the callback. If the connection type is default then this will be perfectly thread safe.
Though you should create a QByteArray from data to pass around as data will likely not be valid by the time the slots get called.
void callback(..., void* user){
//user is the standard void* in most callbacks passed as reinterpret_cast<void*>(this)
unsigned char* data = ...;
QByteArray bytes(data);
emit reinterpret_cast<PhMidiInput>(user)->quarterFrame(bytes);//calling the signal which will behave as you'd expect
}
In the last connect() call you pass this and MidiTest::onQuarterFrame as the receiver object and method. I bet this is not an instance of MidiTest, is it?
The problem here is that you're passing SLOT method from MidiTest, while the receiver object is this, which is not instance of MidiTest. Change receiver from this to some instance of MidiTest.
I'm surprised this code doesn't crash your application when running.
I am having a very strange problem with QObject::connect method. First please take a look at this very straightforward code:
class B : public QWidget {
Q_OBJECT
public:
explicit B(QWidget* parent = 0) : QWidget(parent) { }
signals:
void event();
}
class A : public QObject {
Q_OBJECT
public:
explicit A(QWidget* parent = 0) : QObject(parent) { b = new B(parent); init(); }
void init() { QObject::connect(b, SIGNAL(event()), this, SLOT(handler())); }
public slots:
void handler() { /*spit out some text*/ }
private:
B* b;
}
An object of A does not respond to signals emitted from object of B. I am confident that the signal is emitted as expected. The QObject::connect method return true indicating success. I ran qmake, moc and the moc_.cpp* files seems correct.
I wonder where my did I make mistake?
Edit I:
Here is the code I am working on, it is stripped down so only the relevant parts are shown:
class ListController : public QObject {
Q_OBJECT
public:
explicit ListController(Model* model, QWidget* parent = 0) : QObject(parent) { compositeView = new CompositeView(parent); initConnections(); }
void initConnections() { QObject::connect(compositeView->getListView(), SIGNAL(event()), this, SLOT(handler())); }
public slots:
void handler() { qDebug()<<"signal is received ..."; }
private:
CompositeView* view;
};
class CompositeView: public QGroupBox {
Q_OBJECT
public:
explicit CompositeView(QWidget* parent = 0) : QGroupBox(parent) { listView = new ListView(this); }
ListView* getListView() const { return listView; }
private:
ListView* listView;
};
class ListView : public QListWidget {
Q_OBJECT
public:
explicit ListView(QWidget* parent = 0) : QListWidget(parent) { }
protected:
void dropEvent(QDropEvent *event) { emit signal(); }
signals:
void signal();
};
I create a new ListController object inside a QWidget subclass passing itself as a parent and providing an appropriate Model object.
Edit II
The ListController returns CompositeView object to the main widget. the main widget adds the the composite view to its layout. At this point the parent of the CompositeView and its children is changed. Which might be the source of the problem.
The answer of this problem was way much easier than I expected.
I think I made a mistake of doing the following steps:
ListController is created on the stack.
The CompositeView object is returned and added to the main widget layout.
ListController object goes silently out of scope and gets destroyed and consequently the connection.
Comment 13 from the top was actually the solution. Thanks a lot tmpearce for your advice.
singals:
void signal();
I doubt, if it the actual code you are working, then please check the typo error.
I would like to know which of the following is the proper way of doing thing with signal/slot in Qt.
I need a way to have multiple instance of a Dialog, i.e: A and B. And I need to tell A to print "A" and B to print "B" from a different thread. So I believe I need something like either:
OPTION 1) A->print("A") and B->print("B")
or is it better to do:
OPTION 2) emit print("A") and emit print("B") and use a way that I don't know so only A catch the "A" and only B catch the "B".
I got the option 1 working like this:
class myClass : public QMainWindow
{
Q_OBJECT
public:
myClass (QWidget *parent = 0, Qt::WFlags flags = 0);
~myClass ();
void doPrint(char* text)
{
emit mySignal(text);
}
private:
Ui::myClass ui;
public slots:
void newLog(char* msg);
signals:
void mySignal(char* msg);
};
myClass::myClass(QWidget *parent, Qt::WFlags flags) : QMainWindow(parent, flags)
{
ui.setupUi(this);
connect(this, SIGNAL(mySignal(char*)), this, SLOT(newLog(char*)));
}
void myClass::newLog(char* msg)
{
ui.textEdit->append(msg);
}
and then all I have to do is:
myClass* instanceA = new myClass();
myClass* instanceB = new myClass();
instanceA->doPrint("A");
instanceB->doPrint("B");
is this right?
Thanks!
Since your slot is in another thread, you have to use the Meta-Object System to invoke the method asynchronously. The proper way to do this is to use QMetaObject::invokeMethod
DO NOT subclass QThread and override the run method. For details on this see: https://www.qt.io/blog/2010/06/17/youre-doing-it-wrong
void otherClass::printTo(myClass* instance, char* text)
{
QMetaObject::invokeMethod(instance, // pointer to a QObject
"doPrint", // member name (no parameters here)
Qt::QueuedConnection, // connection type
Q_ARG(char*, text)); // parameters
}
void myClass::doPrint(char* text)
{
ui.textEdit->append(text);
}
myClass* instanceA = new myClass();
myClass* instanceB = new myClass();
printTo(instanceA, "A");
printTo(instanceB, "B");
If the char* type hasn't been registered with the Meta-Object System yet, do so with
Q_DECLARE_METATYPE(char*);
then:
qRegisterMetaType<char*>("charPtr");
In this simplified example, I think you are on the correct path with option 1. However, it would be even better if you didn't need the doPrint() method, which would also eliminate the need for the mySignal signal (at least in myClass). Instead, I would suggest inheriting your threads from QThread if the aren't already, and doing something like this:
class myThread : public QThread
{
Q_OBJECT
public:
myThread (QWidget *parent = 0 ) : QThread(parent) {}
~myThread () {}
void run(char* text)
{
emit mySignal(text);
}
signals:
void mySignal(char* msg);
};
Then you need to do something like this:
myClass* instanceA = new myClass();
myThread* threadA = new myThread();
connect(threadA, SIGNAL(mySignal(char*)), instanceA, SLOT(newLog(char*)), Qt::QueuedConnection);
threadA->run( "A" );
Obviously, in most non-example code, you'd not pass the string into run, but rather generate strings to be run as threadA is running. The advantage is that this keeps the thread considerations out of myClass, and you only need to think about them where they are connected. On the flip side, you introduce fewer dependencies into the threads, since they don't need to know about myClass to be able to log.