General and Desktop

@Kaguro said in QUdpSocket broadcast messages with more ip address: If someone has more IP addresses (for virtualmachine etc...) then they didnt get any messages but if some has just one ip address then he could send messages to everyone and recieve from everyone. If we set QHostAddress::Broadcast to 10.0.10.255 (this is our IP range) then everything is working correctly for everyone. Sounds like you didn't bind to the correct address on the receiver side. So the question is how does it work? Well, you could use a multicast group with UDP, to mix and match the different interfaces you have defined.

@AnneRanch said in Please help me spot my ( C++) code error: Should have compiler complained about my double declaration of t? No. QTimer * t = new QTimer(this); //< Declare t and initialize it t = new QTimer(this); //< Assign to t; no double declaration Consider: QTimer * const t = new QTimer(this); //< Declare t and initialize it, the pointer is immutable t = new QTimer(this); //< Compiler complains - sorry, no can do, the pointer is const

@SGaist said in How to insert new record in a QSqlRelationalTableModel: Use the dialog to get the data from your application user. Then create the record based on the data you extract from the dialog. I 'll do it this way.

@SimonSchroeder said in Runnning (C++) function in background: In that case I just use QMetaObject::invokeMethod(qApp(), progressDialog,progress { progressDialog->setValue(progress); }) If you're going to use invokeMethod you might as well not pass it unnecessarily through the application object - you already have the correct context object. QMetaObject::invokeMethod(progressDialog, std::bind(&QProgressDialog::setValue, progressDialog, progress)); You could alternatively post a custom event to the dialog with QCoreApplication::postEvent.

@Antoine3616 possibly/typically this is a x86/x64 mismatch issue or, minnow/msvc issue. Usually a problem caused by the person who shipped that program to you or you have somehow an other qt installation in your system path, that is a mismatch and causes the issue. Than its on you :D

@surajj4837 said in Deploy UI file on QNX: This step is not happening What does this mean please? Post error message or describe better what happens. Do you have CMake in your QNX SDK?

@kkoehne Thanks

@Christian-Ehrlicher, thank you, just realised the same during debugging.

@jars121 just in case you're still looking for a solution to your original question, and/or someone else finds his/her way over google to here: #include <array> class SomeClass : public QObject { Q_OBJECT typedef void (SomeClass::*SomeClassFunction)(); std::array<SomeClassFunction,3> arrayOfSignalsPointers{&SomeClass::signal1,&SomeClass::signal2, &SomeClass::signal3}; std::array<SomeClassFunction, 3> arrayOfSlotsPointers{&SomeClass::slot1, &SomeClass::slot2, &SomeClass::slot3}; public: explicit SomeClass(QObject *parent = nullptr) : QObject(parent) { QObject::connect(this, &SomeClass::signal1, this, &SomeClass::slot1); QObject::connect(this, &SomeClass::signal2, this, &SomeClass::slot2); QObject::connect(this, &SomeClass::signal3, this, &SomeClass::slot3); qDebug() << "Emit all signals"; for(auto entry : arrayOfSignalsPointers){ (this->*entry)(); } qDebug() << "Call all slots directly"; for(auto entry : arrayOfSlotsPointers){ (this->*entry)(); } } signals: void signal1(); void signal2(); void signal3(); public slots: void slot1(){qDebug() << Q_FUNC_INFO;} void slot2(){qDebug() << Q_FUNC_INFO;} void slot3(){qDebug() << Q_FUNC_INFO;} };

It took me a while to get to the bottom of this because the error I was getting was neither straightforward (nor consistent after I switched to a debug build), but here is, in essence, what happened: I was keeping track of references to the runners with QSharedPointers. I had popped the reference off the list, put it in a QVariant, and passed it along with the runner. Evidently, this didn't prevent the reference count from dropping to zero, and the object was deleted some time shortly after the thread started executing. It was just a dummy object for testing, so it managed to complete execution before the objects' deletion, but wasn't able to live long enough to emit the signal.

@tham said in Insert data into sqlite is very slow by QSqlQuery: I find the solution, the answer is do not use execBatch, this api is ultra slow for sqlite database, you should start a transaction first and bind your value in for loop + exec qDebug()<<"can start a transaction:"<<QSqlDatabase::database().transaction(); for(int i = 0; i != data_table.id.size(); ++i){ query.bindValue(0, data_table.id[i]); query.bindValue(1, data_table.room[i]); query.bindValue(2, data_table.name[i]); query.exec(); } qDebug()<<"end transaction:"<<QSqlDatabase::database().commit(); With this solution, I am able to insert 663581 data in one second, much faster than execBatch(around 180 data in one second). Both of them have the same pragma setting. PRAGMA synchronous = OFF PRAGMA journal_mode = MEMORY Awesome😆

ever hear of macro guarded code inclusion and .gitignore?

syntax from documentation for border <width>px <border-style> <border-color> That's mean it should be px after border.

Hi @mchinand, thanks! It works perfectly.

@JKSH Thanks!

@SPlatten You're right, I missed setIcon() in QAbstractButton. No need to paint anything, good to know.

@Panoss said in How can a child form use parent 's form model: but it crashes on the last line That's what a debugger is for! Run it in debugger, allow to crash, look at stack trace window. If a line "crashes", break it into separate code to test intermediate results. For all I know there may not even be a fieldIndex("name")....

Sorry for my English. This problem is caused by qstringlist. In the code, I use qstringlist to store the original data collected by the sensor (the data type is int,I use qstring::number to convert int to qstring ), store it once per second, write the data to the file every ten minutes and empty the qstringlist. When the number of qstringlist elements exceeds 2 million (not fixed, related to the number of threads (running the same code: saving, writing files, emptying) and the number of such qstringlists), the program will crash automatically after running for a period of time (under MinGW compiler, the program will exit directly; under mvsc compiler, the program interface will turn white and get stuck). I guess the reason is that the list will generate memory fragments. With the increase of program running time, such memory fragments will increase (there are many vectors with variable length in my program that will be generated and destroyed every second. Under the interaction of the two, there will be less and less large continuous memory left in the memory). Therefore, after the program runs for a period of time, when executing "for (int j = 0; J < x_dataforsave. Size(); j + +) {data1. Append...}", there is not enough continuous memory left for data1 (qstring stores its data in an array of char type). The program crashes because it can't allocate memory, and sometimes QT doesn't give a warning. To solve this problem, I use qvector < int > to store the data collected by the sensor, and use fromrawbyte to get qbytearray. Because I don't know much about the basic principle of computer, I have been perplexed by this problem for a long time. I hope this answer can be helpful to people with similar confusion. Thank @ JonB for your help. I find It is not convenient to use debugger to locate such problems, because the time of program crash is not fixed, and the program has many threads, so it is difficult to locate them by breaking points; If I don't break the point, the program will exit automatically, and the debugger won't stay at the moment when the program crashes.