Hi and welcome to devnet, From the looks of it, you are likely accessing the QPushButton directly from your custom thread which is forbidden. GUI element manipulation shall happen in the main thread.

to continue the point @Christian-Ehrlicher mentioned above, blocking serial tasks usually exist on server daemon applications, but not on anything with user interaction or a GUI.

@duckrae List your client with id, when you are getting new incomingConnection. server can reply as per client id to a specific client or reply to all.

@duckrae said in How to write another Thread data in txt file?: How can I handle it? Simply emit the signal: QTimer *timer = new QTimer(this) timer->start(60000); emit myTimeoutSignal(text);

@duckrae First remove all that thread stuff

Hi, Please use coding tags for your code, that will make it readable. You are using several different instance of sps2data that are unrelated to each other. On a side note, you should always instanciate QXXXApplication before any other QObject based classes.

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

@jsulm I just now noticed this when I was debugging the code and was about to update here but I see u have already answered it. Thanks

Thank you for your advice. I did as you said and it seems it's working well.

@Dariusz Can you help with the solution that you did to solve the cmake error that you were getting : CMake Error at C:/Qt/6.1.0/msvc2019_64/lib/cmake/Qt6/QtFeature.cmake:1017 (message): Feature poll_select is already defined and has a different value when importing features from Qt6::Core. I am getting the same error when I moved to Qt 6.1. Using the static libs of Qt, built from source.

@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

@SGaist said in QTimer & Thread, adding it to running thread...: With only bits of your code it's not possible to understand your implementation and the possible issues you might be facing. Today is special day for my brain and I literally fail at basics... I forgot to start the worker... thus its event loop never run... thus it never started the damn timmer... ehhh!!!! Everything works fine once I started the worker... yayyyy I learned something new! :- )

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.

Humor me, will you? constexpr int poolSize = 16; QVector<QThread *> threadPool(poolSize); QCoreApplication * app = QCoreApplication::instance(); for (size_t i = 0; i < poolSize; i++) { QThread * thread = new QThread(app); thread->start(); QObject::connect(thread, &QThread::finished, thread, &QThread::deleteLater); } QObject::connect(app, &QCoreApplication::aboutToQuit, [threadPool] () -> void { for (QThread * thread : threadPool) { thread->quit(); thread->wait(); } }); int index = 0; for (const QString &video : videoFiles) { ThumbnailExtractor *extractor = new ThumbnailExtractor(counter, folderPath + '/' + video); extractor->moveToThread(threadPool[index++ % poolSize]); QObject::connect(extractor, &ThumbnailExtractor::finished, extractor, &QObject::deleteLater); QMetaObject::invokeMethod(extractor, &ThumbnailExtractor::generateThumbnail, Qt::QueuedConnection); } A note here: QMediaPlayer and related classes don't seem to be reentrant so you can't use them from different threads. Stick to the main one.

Hi, You can connect the "finished()" signal to a slot and there check if all threads are not running. I assume that you have a list of threads.

@CJha said in How to use full processing power available to do calculations?: If I use more threads by using QtConcurrent::mapped() or QThreadPool from inside a non-GUI thread, will it use this non-GUI calling thread as well? To make my point more clear: Let's say I create a thread called A and based on the number of cores my CPU has I have thread B, C and D available. After my thread A calls either QtConcurrent::mapped() or QThreadPool to start the calculation it has nothing more to do till the calculation finishes, so will it wait idle while my calculations are running in other threads or will QtConcurrent::mapped() or QThreadPool include thread A along with B, C and D to do the calculations? We need to know: How do you create thread A? QtConcurrent uses the global QThreadPool behind the scenes. If thread A is not part of the pool, then it won't be used by the pool to do calculations when it is idle. Is there any way I could run a single loop (major loop of my calculation) in multiple threads with different data sets without using QtConcurrent::run()? QtConcurrent::mapped() will not work as it has requirements that there should be a return type which is not always the case with my calculations. QThreadPool, QRunnable and especially QThreadPool::globalInstance() documentation is not enough for me to make this judgement. QtConcurrent::map() (not mapped()!) does not return any values. You can interface with it using QFuture<void>. See https://doc.qt.io/qt-5/qtconcurrentmap.html#concurrent-map Finally, is there a better/simpler approach to solving this problem? Experiment with QtConcurrent::map() and see if it suits your application. NOTE: I have placed the same question in Stack Overflow as well. As a courtesy to other users, please link your duplicate questions to each other. This way, people can see if your question has been resolved and get the answer too

Install a Qt message handler, set a breakpoint in there and take a look at the backtrace where it comes from.

@Cocojambo said in Load balancing between several Threads: I mean that all 4 new threads may be created in one core and we won't get any benefit of such multi threading. You can't with Qt. But the OS will for sure not put all four threads on one core and leave the other three idle when the four have something to do.

Looks like you are re-implementing tools that already exist for that purpose. Was tmux/xpanes considered ? In any case, before doing any threading, you should have a proper encapsulation for your connection and command sending. Once you have that you can start thinking about threads or maybe use QtConcurrent. It looks like you rather have lists of commands to send to machines. A bit like what ansible manages for you with its playbook.

That question is being answered on this thread.

@mvsri said in QT QImage Read From Error: image_path is nothing but a QString which stores the path to a bmp image in a folder. the path is static it doesn't change. I know that! My question is about the content of that file. I don't know whether the image writing is finished or not. that's why i used QFile exists to check if the file is created or not and read the image if the path exists. But that doesn't tell you anything about whether it has started but not finished writing to that file, does it? (Unless you are relying on Windows or something not allowing a file to satisfy "exists" until it has been closed, which I would see as dodgy in the extreme.) In which case, you will read in an incomplete image file, maybe that's why you have "black" at the bottom? At least put in a qDebug() << image.sizeInBytes() after loading it (though I'm not sure if that's reliable).... QFile::remove(image_path); It gets worse! This, or renaming: how do you know that at the instant you execute this the camera has not re-started writing to that file for the next capture, and you are (trying to) removing/renaming a file while it is being written anew? Is your camera-image-capture-write-to-file a separate process from your code? How do you know when the capture has started/finished writing to the file?

Congratulation and thank you for the fix :-)

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());

@Dariusz Sorry to make a post to just confirm what @SGaist has said above, but 20 * 75 == 1,500-odd line edits average. That's a lot! (And I pity the user who has to fill those in ;-) ) I think the suggestion that you look at the possibility of some kind of table instead needs reiterating. And @VRonin will then be here to ensure that you achieve this using item delegates instead of widgets in your table, so it will all be fast and not use up too much memory/resources ;-)

@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