By the way, how are your buttons connected ?
You might want to rather call the dialog's accept slot from on_buttonBox_accepted rather than connecting it directly to your button.

Can you share the code you are using ?
Do you get any warning about a timer being in the wrong thread ?

@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.

@Bonnie said in QThread does not quit, why?:

The solution is

QObject::connect(myControl, &Control::finished, myThread, &QThread::quit, Qt::DirectConnection);

And where does it say that this slot is thread-safe?

@robro
Just quit the thread before you exit the application.

QObject::connect(&app, &QApplication::aboutToQuit, myCtrl, &Control::deleteLater); QObject::connect(myCtrl, &Control::finished, &myThread, &QThread::quit); QObject::connect(&myThread, &QThread::finished, myCtrl, &Control::deleteLater); //< This is needed

Which translates simply to:

qDebug() << "Started Waiting:"; myThread.quit(); myThread.wait(); // Wait for thread to quit qDebug() << "Quit";

@Christian-Ehrlicher Thank you very much! It solved my problem perfectly :)

@TMJJ001 said in QTimers and QThreads:

connect(&cThread,SIGNAL(started()),this,SLOT(DoWork()));

You do NOT execute DoWork() in that thread, you execute it in the GUI thread.
Take a closer look at the example here: https://doc.qt.io/qt-5/qthread.html

The ellipsis are showing up correctly now that I'm using a consistent compiler for my tests.
I still have many bugs to fix, but got the first release out the door.
Thanks again for all of your help!

@Dariusz said in Move EVERY QObject to main thread and more...:

Print every QObject in-app.

No. You can get all the children for a given root QObject though: object->findChildren<QObject *>()

Get each object thread

QObject::thread() for the object's associated thread (i.e. depending on its affinity), QThread::currentThread() for the thread object associated with the current context (and yes, these can differ).

Move object to the main thread.

Only from the thread the QObject belongs to, no other. QObject instances can only be "pushed" into another thread from their own thread, but not "pulled" from their thread from another.
To move the object, you do what you usually do:

object->moveToThread(QCoreApplication::instance()->thread());

@nintyfan said in Creating widgets in "another" thread...:

Signal is not solution, because QApplication::exec could not been called yet

So how do you show the push button then? Your design looks flawed.

@pauledd
I would recommend using the build-in QThread mechanism to interrupt a thread:

public slots: void doWork() { forever() { ... if ( QThread::currentThread()->isInterruptionRequested() ) { return; } ... } }

You can add this check to your SPI loop multiple times but avoid to call it too often, according to the dokumentation.
Add something like this to your MainWindow-Instance:

public slots: void cancel() { if( thread.isRunning()) { thread.requestInterruption(); } }

and connect this Slot to some Cancel-Button.

QObject has no event loop, the event loop is in QCoreApplication and siblings.

You can not just stop the one from you main application. As for QThread you can interrupt the thread but I'm really not sure that's the best way to handle your situation.

From the looks of it, you seem to have to create a queue of the events received and store these there while in pause mode and then empty that queue on restart if that makes sense.

You're welcome !

Since you have it working now, please mark the thread as solved using the "Topic Tools" button so other forum users may know a solution has been found :-)

Seems the cache hid the fact that you did everything already !

Few place I read, it is generated due to some issue with kernel. So I just update the Ubuntu LTS, and Now it is working with same code.

I CUDA not build it unfortunately. CUDA is only supported in Visual Studio for Windows so I guess its back to good old uncle GL ...

@Christian-Ehrlicher The thread don't get autodeleted once it runned its empty function? o.O I need to test it! :D

@sgaist said in Building a "complex" progress widget:

Don't try to steal anything. Use signals and slots to communicate from your secondary threads back to your main thread.

Yes, but as far as I can tell the main thread is "working" (or user has took control over it) as it spawned the secondary threads and is waiting for them to finish processing before moving on.

Edit
Ok so I've now run QMetaObject::invokeMethod(this,={callToLongFunction},Qt::QueuedConnection);
This appear to work, however any loop that was being

#pragma omp parallel for
for (){}

No longer threads... so qt somehow manages to break the omp multithreading ? -- well standalone teste indicates that no... all works there but my app stopped threading... sweet.

Ok I'm a nub, its official! Everything works. It threads & runs job in qt internal event loop thus I don't have any issues. Wow. Ok I need to learn more on qt threading event loop :D I need to fork one for myself and have it process all my work stuff now :- ))

EDIT...

Ok seems like I did a full loop. I went from processing in user thread to processing in qt event loop - fine - but pragma still wont update the widget at the correct time... sigh. Since now we are in event loop, the processing of function is more important than processing of omp thread update signal... I need some kind of priority attached to signal to tell qt that hey... I know u have ur loop but process this signal now.
Right now with Qt::DirectConnection while trying to update val/etc I get this >

###### WARNING: QWidget::repaint: Recursive repaint detected ((null):0, (null)) ###### ###### WARNING: QBackingStore::endPaint() called with active painter on backingstore paint device ((null):0, (null)) ######

And aparently by putting this inside omp seems to "work"...

if (omp_get_thread_num() == 0) { qApp->processEvents(); } ```... ahhhh multithreading <3

@VinayBalajiRajputh said in Busy indicator in QML:

I have tried adding log messages and it seems only after the function open file is finished all the messages are logged

IMHO that's the expected behavior as you are not using thread and make everything in a function the events are blocked until execution is finished.

What you can do if to provide a property from TestClass whic indicates if thread is running, and then bind this property with the BusyIndicator.

But just a warning about the thread part, as I'm not an expert I reused your code with some modification for creating and starting the thread. But I don't think this is the correct way to use threads. I recommend that you read carefully QThread documentation, there is a nice example of how to use worker objects by moving them to the thread using QObject::moveToThread(). There are also other ways like QThreadPool and QRunnable or QtConcurrent.
There are also plenty of post on this forum and many others about how to use QThread

import QtQuick 2.10 import QtQuick.Window 2.10 //Post: https://forum.qt.io/topic/104906/busy-indicator-in-qml/3 import QtQuick 2.4 import QtQuick.Controls 1.3 import QtQuick.Window 2.2 import QtQuick.Dialogs 1.2 ApplicationWindow { title: qsTr("Hello World") width: 640 height: 480 visible: true Connections{ target: obj onIsRunningChanged: console.log("Running: " + obj.isRunning) } BusyIndicator { id: indicator running: obj.isRunning anchors.centerIn: parent } Button { text: "start" anchors.top: parent.top anchors.horizontalCenter: parent.horizontalCenter onClicked: obj.runWorkerFuntion() } }

c++

//testclass.h #ifndef TESTCLASS_H #define TESTCLASS_H #include <QObject> class TestClass : public QObject { Q_OBJECT Q_PROPERTY(bool isRunning READ isRunning NOTIFY isRunningChanged) bool m_isRunning = false; void workerFunction(); public: explicit TestClass(QObject *parent = nullptr); bool isRunning() const; public slots: void runWorkerFuntion(); signals: void isRunningChanged(bool isRunning); protected slots: void setIsRunning(bool isRunning); void threadStarted(); void threadFinished(); }; #endif // TESTCLASS_H testclass.cpp #include "testclass.h" #include <QThread> #include <QDebug> TestClass::TestClass(QObject *parent) : QObject(parent) {} bool TestClass::isRunning() const { return m_isRunning; } void TestClass::runWorkerFuntion() { qDebug() << "runWorkerFuntion() from main thread: " << QThread::currentThreadId(); // /!\ THIS IS NOT A GOOD WAY TO USE THREAD QThread* thread = QThread::create([this](){ workerFunction(); }); connect(thread, &QThread::started, this, &TestClass::threadStarted); connect(thread, &QThread::finished, this, &TestClass::threadFinished); connect(thread, &QThread::finished, thread, &QObject::deleteLater); thread->start(); } void TestClass::workerFunction() { qDebug() << "workerFunction() from thread: " << QThread::currentThreadId(); QThread::sleep(1); } void TestClass::setIsRunning(bool isRunning) { if (m_isRunning == isRunning) return; m_isRunning = isRunning; emit isRunningChanged(m_isRunning); } void TestClass::threadStarted() { setIsRunning(true); } void TestClass::threadFinished() { setIsRunning(false); }

console output:

runWorkerFuntion() from main thread: 0x4228 workerFunction() from thread: 0x15a4 qml: Running: true qml: Running: false

@Gojir4 thanks, I am trying that right now. I’ve added a 1s delay in my image grabbing thread. Let’s see. Fingers crossed!