@SGaist Thank you, I get it.

@VRonin

I misread your reply.
Was looking at the functor code and thought, huh, why you need C++11 or below.
Missed that you referred with "lambda" to the code sample 1-2 posts earlier.

Yes, the lambda, in which I tell std::max_element how to compare, works.
I still take this as a chance to re-think what I'm doing and if there is a better way.

Thank you :)

@tonystark Please do what is usually suggested here in such cases: set QT_DEBUG_PLUGINS env variable before starting your app and post its output here.

I would do so, yes. Even though I would not expect a threading problem with qFindChild as long as the object tree is not changing but one never knows.

@Pl45m4 Calling slots as a normal function directly from main thread, reading/writing from/to a variable of QObject (using mutex of course).

@ugo_ I'm failing to see CMAKE_AUTOMOC in your cmake file, did you forget to enable moc for your project?

Nope, I'm just blind :D

@kuzulis Thank you so much for your response. That is a great idea.
But you are right, the communication protocol would make a lot more sense if it followed the <length><data><crc> structure.

@JonB 's Idea works well with my existing Program structure.

Ok thanks! I think I understand what I have to do

@JonB Hi, sorry for the late reply.
extacly, i already have signal parameter, only want to write generic mathod - which has its own inbuilt signal-side parameters for connect() but accepts the slot-side as parameters.

@VRonin Solved! Thanks for your time!

@mrjj and @raven-worx , thanks for the replies! What I've gathered from this (and other posts) is: you can't use a Q_ENUM outside of QObject or a Q_GADGET macro. So in order to do what I wanted I need to change the code like this:

#ifndef EXAMPLE_H #define EXAMPLE_H #include <QObject> struct Player { Q_GADGET public: enum class CarType { NO_CAR = 0, SLOW_CAR, FAST_CAR, HYPER_CAR }; Q_ENUM(CarType) Q_PROPERTY(Player player READ getPlayer) Q_PROPERTY(float m_speed READ getSpeed) Q_PROPERTY(CarType m_carType READ getCarType) Player getPlayer() { return *this;} float getSpeed() {return m_speed;} CarType getCarType() { return m_carType;} public: CarType m_carType; float m_speed; }; Q_DECLARE_METATYPE(Player) #endif #include <QCoreApplication> #include <iostream> #include <QMetaObject> #include "example.h" #include <QDebug> #include <QMetaProperty> int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); qRegisterMetaType<Player>(); const QMetaObject* metaObject = &Player::staticMetaObject; qInfo() << "Number of enums is: " << metaObject->enumeratorCount(); const QMetaEnum metaEnum = metaObject->enumerator(0); qInfo() << "Enum name: " << metaEnum.enumName(); int i = 0; for(i = 0; i < metaEnum.keyCount(); i++) qInfo() << "Enum key: " << metaEnum.key(i) << "; Value: " << metaEnum.value(i); return a.exec(); }

Thanks for your time!

@JonB I understand the usual paradigm, but my code is made in such a way so that the sender object is hidden, and so there is not really any place where header files from both sender and receiver are included simultaneously. This is to maintain modularity in the code.

However, by using:

connect(this, SIGNAL(testConnection()), receiver, method);

in the sender it recognizes that I am trying to connect to Receiver::testConnection() and it has the pointer to the receiver passed to it, then in theory it should be capable of connecting its signal to the receiver's slot with only this much information about the receiver.

Then maybe something like the json based plugin metadata used by Qt and Qt Creator.

@Dariusz said in How to properly delete threads& objects in them ?:

So in general, moving object to another thread does not set the thread as it parent does it.

No because the function is called moveToThread and not moveToThreadAndDoOtherStuffLikeSettingaParent

My dumb ass set the socket thread to nullptr 1 function before and then I was scratching my head why thread() was retuning QObejct(0x0) and I could not test against nullptr/etc... I'm gifted

Sorted.

@Kyeiv said in ListView model from Q_PROPERTY problems:

What am i doing wrong that the view is empty?

The problem is that QList<QString>() is not a valid type for a QML model!

QML model can be QList<QObject*>() or QStringList() (cf https://doc.qt.io/qt-5/qtquick-modelviewsdata-cppmodels.html).

Change your Q_PROPERTY from QList<QString> to QStringList and it will work as expected.

@amina said in inheritance problem:

it is working now

great, so don't forget to mark your post as solved!

@Christian-Ehrlicher thank you, i understand my mistake and solve it.

As @Christian-Ehrlicher already said: the image gets deleted when the thread object is deleted. Do you delete the thread object?

Furthermore, I am not sure how you are trying to check if the memory is actually freed. The operating system might not be able to show you this. Your software will request memory from the OS when necessary, but can choose to keep it for later allocations when memory is freed. The only way you can test this is by repeatedly allocating and deallocating an image. If the memory usage does not grow then memory is correctly freed even if the OS does not show you this.

So it looks like I was missing the variable statement after this. It works now. Thanks everyone for the help.

QList<QObject*> list() const; for (int index=0; index < list.size(); index++) { QObject *test01 = list.value(0)->name(); qDebug() << test01; }