@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

opencv (extra characters to make response longer than 8 characters...lame!)

Thank you all dear friends, that’s really kind of you. Your help is so appreciated.

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 !

@The178 Hi On your first post [image: yTIrPw.png]

@Kent-Dorfman that was my bad, the actual name in the code is different (I didn't want to use the original since it could potentially disclose information I am not allowed to share) and I wasn't creative enough to think of something so I said timer1 haha. The actual variable is all letters :).

@dheerendra Okay, done, thank you for reminding!

Why are they not ?

@Buckwheat Thank you documents link. I will read it and trying to make change in my code. thank you @Buckwheat .

void MainWindow::doThat() { // private: int m_numDestroyed; m_numDestroyed = 0; for(QTimer*& singleTim : {timerA ,timerB ,timerC }){ singleTim = new QTimer(this); singleTim ->setInterval(100); singleTim->setSingleShot(true); } const auto checkDestroyed=[=]()->void{ if(++m_numDestroyed>1){ delete numDestroyed; timerC->start(); }; connect(timerA,&QTimer::timeout,this,[=]()->void{ qDebug("slot A"); checkDestroyed(); } }); connect(timerB,&QTimer::timeout,this,[=]()->void{ qDebug("slot B"); checkDestroyed(); } }); connect(timerC,&QTimer::timeout,this,[=]()->void{ qDebug("slot C"); } }); connect(timerA,&QTimer::timeout,timerA,&QTimer::deleteLater); connect(timerB,&QTimer::timeout,timerB,&QTimer::deleteLater); timerA->start(); timerB->start(); }

@SGaist I need the slot send_console_log to be called when the signal written in ConsoleStream is emitted. When running the program with a normal while/for loop in the interpreter, the slot will be called becuase at that moment its non blocking. But the moment I add time.sleep into a loop, slots will only be called at the end when all the blocking is over. Thank you for looking into this.

@SGaist Thanks for suggesting OpenGL, I think that might be a possibility at some point. As of now, I got it to work by locking the UI updates and batch repainting all of the windows at once: for(auto widget : qApp->topLevelWidgets()){ widget->setUpdatesEnabled(true); } qApp->processEvents(); for(auto widget : qApp->topLevelWidgets()){ widget->setUpdatesEnabled(false); } I know this may not be the best way to achieve this, so I am all ears if there's any better way to limit UI updates to a single point in execution. Thanks!

@mrjj as i told you in the thread, it looks the same as on your picture. But it should be transparent, so you can see the code lines from the editor below in your case. But let's continue that in the other thread

Never mind, I had code in my the constructor of the to be threaded class, that caused the conflict... connect(&modbusThread, &QThread::started, modbusDevice, &Modbus::setupClass); fixed the issue.

QProcess that is.

@VRonin Yep - you're absolutely right. It's unfinished code and currently a draft to start off with a ID range of 1 as a proof of concept. Will take you input into account - Thanks a lot!

My bad, from your last post, I understood that you replaced the deleteLater call by a new allocation. Why are you calling delete right after deleteLater ?

@slilly said: Can QTimer be called from a normal C++ main and not a QThread or a main using a QCoreApplication? No. If you want to use QTimer, then you need QCoreApplication::exec() or QThread::exec().

@DougyDrumz Easy peasy ... no one seems to want to answer my questions though. ;) Happy coding!

@SGaist you should have to modify QAbtractSocket Seems like you right. The code in 'qabstractsocket.cpp': <...skipped...> // Start the connect timer. if (threadData->hasEventDispatcher()) { if (!connectTimer) { connectTimer = new QTimer(q); QObject::connect(connectTimer, SIGNAL(timeout()), q, SLOT(_q_abortConnectionAttempt()), Qt::DirectConnection); } connectTimer->start(QT_CONNECT_TIMEOUT); } <...skipped...> And there are no options to disable it. But I think it will be easy to patch it to make it work without connectTimer. But use a single timeout for thought of sockets ? Sounds strange. What else can I do to avoid handles exhaustion? I don't see any other options. Out of curiosity, why do you need so many sockets ? Just testing Qt abilities and limitations in this particular area.