@IgKh Thank you for your precious help, things are a lot clearer now. Further tests have shown that most of the features I need still work without a call to exec(). I still can't quite understand what in my example started the event loop or if Qt just plugs in the existing NSApplication's event loop.

@IgKh said in Building a DLL on macOS for a non Qt application:

Had no effect on the main issue though

Can you, just for sake of clarity, state the remaining issues?

The main issue i refered to was me wanting to have a separate thread with a QApplication in it and the Qt::AA_PluginApplication attribute had no effect on this. The other issues I have are not within the scope of this topic though.

Thank you very much !

@SGaist I have QApplication - gui one. ah yes the int main() is just a quick hack/example... there full widget app with buttons running :- )

Also I got it to work, I ended up getting nested futures, and the path to fix that is .unwrap()>https://doc.qt.io/qt-6/qfuture.html#unwrap
Seems to work! :D

Threading and linking to context still seem to be broken tho o.o

@JuanNunez I deleted my first response as I did not realised that it was about a signal and one does not have to implement a signal.
Did you try a complete rebuild after adding signal? Delete build folder, run qmake and build.

@JuanNunez said in How to use the connect:

unresolved overloaded function type

addItem has multiple overloads and the connect cont resolve which one to use.

https://doc.qt.io/qt-5/qtglobal.html#qOverload

also don't use threads. I'm 90% sure you don't know what your doing, and don't need them in the first place

@Dean21 Please show your current code if something does not work...

@Uriel-Machado
Hello and welcome.

Before you go any further: since it is a Qt rule you must not access any UI stuff in a secondary thread --- quite apart from the need for mutexes --- what do you think you are going to access in RadarGUI from a thread anyway?

Threads can send signals to advise the UI thread of something happening and the UI thread can perform the UI action for them.

@StudyQt1 said in Plotting chart using lots of data:

Is there a generic way to decide?

Use a profiler. If you're using GCC you can use https://www.thegeekstuff.com/2012/08/gprof-tutorial/
Easier way which is often enough is simply to put debug output at the beginning and end of your methods/functions with timestamps and then check the output of your application while it is running.

Hi,

Following @KH-219Design suggestion, you should have a task manager rather than relying on the task object itself to do all the job.

@Vivek_A
I note that all your questions are about mongodb, its performance, and so on. Have you tried joining some mongodb forum where these might be better answered?

@LRDPRDX said in In what thread would a QObject be deleted if it was moved to another QThread?:

the dtor must be called and executed in the secondary thread not the main one. Am I right?

Correct, that's what connect(thread, &QThread::finished, worker, &QObject::deleteLater); does and as you noted>

No more events will be processed in the thread, except for deferred deletion events.

Do the deleteLater will still picked up after the finished is emitted and the destructor will run in the secondary thread

Hi,

In addition to @Christian-Ehrlicher, what exactly are you trying to achieve ?

@suslucoder What exactly can't you understand? In the documentation @SGaist posted there is even an example with signal/slot with parameter...

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

@eyllanesc said in PySide2 & Threading... how to set data on widget from thread?:

@Dariusz said in PySide2 & Threading... how to set data on widget from thread?:

Do not implement the same logic in the same class so "manager" should only process the data and send it, then connect that signal to the GUI so that it updates the information. Class Worker(QObject): sendData = Signal(str) def process(self): value = "foo" self.sendData.emit(value) class GUI(QWidget): def apply_data(self, text): self.foo.setText(text) worker = Worker() thread = QThread() worker.moveToThread(thread) gui = GUI() worker.sendData.connect(gui.apply_data) QTimer.singleShot(0, worker.process) By default in the connection AutoConnection is used so since the sender lives in the second thread and the receiver in the main thread then QueuedConnection will be used.

Hmmm thank you, but will this work with python Thread ? As the worker thread, I got is not Qt...

Hi,

In your class declaration.

Note that this is basic C++. If you do not know that, I highly encourage you to first improve your C++ knowledge before going further.

@jsulm: Thank you for your reply. The part I missed is "The default implementation simply calls exec()."

@J.Hilk: Thank you for the great set of examples. IMHO, this should be placed in the QThread Class Documentation.

@ples76 said in Can you create slots in main.cpp file?:

I have solved the problem with all of your help

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

I am trying to find the easiest solution to this since I am under the gun to get this done asap

Although you find a solution now, you may want to take into account that having such a main() function is not a good idea as @Christian-Ehrlicher pointed out.
So time (and stakeholders) permitting, you might want to look at refactoring your code...

@jsulm U are da king!

I am dealing with QML for months, and just learning the property variables! That kinda saved my life mate!
Thank you very much!

Hi guys
I solved this problem by adding a sleeping time duration in my worker thread preventing it from returning too quick. Then the message box gets shown properly and closed properly.

// member function to do the job bool MainWindow::waitReply() { // Here to sleep for a while QThread::sleep(2); bool received_valid_reply = false; while (!m_waitReplyCancelled) { if (Something Is Received) { received_valid_reply = true; return received_valid_reply; } } return received_valid_reply; }

@davidesalvetti Hmm, I am not very confident in your solution. I would create a helper class to create/use right connection according to current thread.
Something like this (it is just a skeleton, not sure it is working as it is):

#include <QSqlDatabase> #include <QThread> class MyBDConnection { QString m_dbPath; QString m_dbName; Q_DISABLE_COPY(MyBDConnection) public: explicit MyBDConnection(const QString &sqlitePath, const QString &cnxName): m_dbPath(sqlitePath), m_dbName(cnxName) {} QSqlDatabase getDBConnection() { // Starting with Qt 5.11, sharing the same connection between threads is not allowed. // Use a dedicated connection for each thread requiring access to the database, // using the thread address as connection name. QSqlDatabase cnx; QString dbName = QStringLiteral("%1_%2").arg(m_dbName).arg(qintptr(QThread::currentThreadId()), 0, 16); if(QSqlDatabase::contains(dbName)) { cnx = QSqlDatabase::database(dbName); } else { cnx = QSqlDatabase::addDatabase(QStringLiteral("QSQLITE"), dbName); cnx.setDatabaseName(m_dbPath); if (!cnx.isValid() || !cnx.open()) { qDebug() << "DB connection creation error!"; } } return cnx; } }

And the only create on instance of this class and pass the pointer to each class which need connection to DB.