@kshegunov said in Function after setupUi():

Probably flooding the main thread's event loop.

Okey I optimized a code little bit:

QtConcurrent::run([=]() { int i; int value; double dResult = 1; for(i = 0;i < 20000000;i++) { dResult = qExp(qCos(qTan(qSin(qPow(qSqrt(((((i * 1337) / 7) * 73) * 1329) % 1937),7) * dResult)) / qAsin(qPow(qSin(dResult * i * qTan(1337 * i)), 29)))); if((i % 200000) == 0) { value = i / 200000; emit showResult(QString::number(dResult)); emit pBarSetValue(value); } } emit showResult(QString::number(dResult)); emit pBarSetValue(100); });

It tooks few seconds for my CPU, but yea UI is responsible and progressbar is changing in realtime

Problem was because

emit showResult(QString::number(dResult)); emit pBarSetValue(i);

runs 5000000 times

I don't follow. Add a stop signal where? You run a function imperatively with the proposed QtConcurent::run (as C++ is an imperative language), you can't just break in the middle of it ...

I dont know, maybe that Quit Application signal will tell to OS scheduler that scheduler has to kill worker thread

So only disadvantage of that method is that I cannot stop worker thread in middle of operation?

//EDIT, thanks for help :)

@ronyNS said:

lbl = new Qlabel();

misspelled ?
its QLabel ?

lbl = new QLabel();
big L ?

That's a brilliant and elegant solution!
Thank you bro for spending your precious time with a newbie like me!

The cause for that crash can be everything!
How should anybody know what it is without your code?
Did you try to debug your program to see where it crashes?

@dxmachina Well, that's not true ;) Just a little mistake. Happy coding! :D

Thank you all. It worked.

@zerocom I had the same issue and your comment helped me to solve it. but this solution seems to be working for predefined number of arguments for invokable functions. is there any way to create an invokable function with variable argument number similar to what we used to do by QScriptContext?

Hi,
Please explain exactly what is the problem

I'd like to add:

Specially if the Watcher needs to be used multiple times it's important to disconnect it after use:

disconnect(FormatWatcher, SIGNAL(finished()), this, SLOT(FinishedFormat())); // disconnect former slot used with watcher

I managed using the following additional lines in CustomCode

QString function = "test(1)"; QJSValue testfunction = myEngine.evaluate(function); qDebug() << testfunction.toString();

With my script CustomLogic.qs looking like this:

function test(x) { var a = "tested!"; a = a + x.toString(); return a; }

Returns "tested!1" in the application output

@ForestPoem In the slot you know which signal was emitted (the one you connected it to), you can even get the pointer to the object which emitted the signal using sender()

@reina
Could you provide us with a usecase? In my experience, a QPixmap only interacts with file storage at initialization and is then a blob of data with an API for internal use.

It's important not to get distracted by the details. The gist of it is simple. Sorta action-reaction setup.

One object emits a parametrized signal and any number of connected objects get a slot invoked with the signal parameter passed.

You have more information about why you can't copy QObject derived class here

@dheerendra said:

You need to get a instance to QObject and type cast to required interface.

From plugin? The QT automatically loads the plugin (qtdir/plugins/webkit/qwebkitplatformplugin.dll), do not know if it is used QPluginLoader, I noticed that if I add qdebug() << "test"; in dll it shows in the main console application, maybe I can use QApplication to share "data".