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

@ForestPoem said:

nArray

thanks.

nArray = arrayNum

It's my mistake. The two are the same

@Stoyan
error: passing 'const Operation' as 'this' argument of 'int Operation::setAttribute(QString, QString)' discards qualifiers [-fpermissive]
operations.at(i).setAttribute(Aname,Value);

Не мога да разбера защо се получава това съобщение в Task класа, опитвайки се да извикам метода SetAttribute за операция във вектора.
Const Operation не знам откъде идва вътре в тази функция конкретно, след като подавам само id-то на операцията.
Подобна е грешката и при Task сетване на атрибут:
scheduledtopservice\scheduler.cpp:31: error: passing 'const Task' as 'this' argument of 'int Task::setAttribute(QString, QString)' discards qualifiers [-fpermissive]
tasks.at(k).setAttribute("state","running");

ПП:
Успях да го реша проблема. Разбрах че .at() връща const обект, затова използвах [i] за индекс.

task.cpp:17: warning: base class 'class BaseObject' should be explicitly initialized in the copy constructor [-Wextra]
Task::Task(const Task &obj)
Това как мога да го оправя, четох че създавало още 1 копие на BaseObject така. Но не е като експлицитния конструктор сякаш : BaseObject ( const BaseObject &obj) ако долепя до Copy конструктора на Task. Не съм сигурен, но май просто като сложих : BaseObject() и се изчисти предупреждението. Така ли трябвa да бъде ?

Hi and welcome to devnet,

In addition to @mrjj, can you show the exact error you have ?

You're welcome !

An outside look from time to time can give some good ideas :)

@SGaist thanks for your reply) Now I'm at least sure that this approach is ok) thanks again for welcome)

@Wieland
Thanks for the lead, I will do some more investigations then.

@koahnig you are great!

I have found the problem. It was a blocking ftp download which did not finish because of broken communication. Pushing the download to a separate thread unveiled the problem respectively made it tracable.

Forgot to add the #include <QTimer> in the mainwindow.h file

:)

When does it start to show that A ?

I asked the same quesion in stackoverflow. I gues I found out why I am having this problem.

http://stackoverflow.com/questions/30686488/qapplication-is-lazy-or-making-other-threads-lazy-in-the-app

I use qml to make it work.WorkerScript

Actually I have since spotted what the problem was, As it turns out creating a new instance of QNetworkAccessManager every 15 seconds is not the best idea if you're not deleting them.

The solution I went with was making *manager a class member.

Hi there,

I'm not completely sure what you are asking. But if I'm understanding you correctly, you
want to implement the timeout() signal in your own way? I would suggest sub-classing the
QTimer object.

#include <QTimer> class CustomTimer : public QTimer { Q_OBJECT public: explicit CustomTimer(QObject *parent = 0); signals: void customSignal(/*parameters*/); public slots: void emitCustomSignal(); }; CustomTimer::CustomTimer(QObject *parent) : QTimer(parent) { connect(this, SIGNAL(timeout()), this, SLOT(emitCustomSignal())); } void CustomTimer::emitCustomSignal() { emit customSignal(/*parameters*/); }

@sirop It's set, I've checked it like this:

void MainWindow::timerUpdate() { static int start = 0; static const size_t loops = 10000; static qint64 nsecs[loops]; static size_t index = 0; static QElapsedTimer* elapsed = new QElapsedTimer(); if(start++ < 10) { elapsed->restart(); qDebug() << "clockType: " << elapsed->clockType(); return; } if(index<loops) { nsecs[index++]=elapsed->nsecsElapsed(); elapsed->restart(); return; } timer->stop(); qint64 maxDev = 0; qint64 avgDev = 0; for( qint64 elapsedTime : nsecs ) { //qDebug() << "Time since last update" << elapsedTime << "nanoseconds"; qint64 dev = 5000000 - elapsedTime; if(dev < 0) { dev = dev*-1; } avgDev += dev; if( dev > maxDev) maxDev = dev; } qDebug() << "Max deviation: " << maxDev; qDebug() << "Avg deviation: " << avgDev/loops; }

With following output:

clockType: 4 Max deviation: 4615989 Avg deviation: 4327

@JKSH Thanks--this helped me solve the problem. In a GUI thread, I was using exit()--when I should have just used emit finished()

Hi,

You can use the Animation Framework for that. But rather than painting on a widget since you seem to be writing a game, you should take a look at the GraphicsView Framework

@Bear35645 You are welcome. Any time again. :)