@jeremy_k
If you're talking about compound widgets, yes of course they use signals.

@trusktr said in Auto re-run property bound code in C++ outside of a class?:

@sierdzio Have a look at Solid.js. People are loving the dependency-tracking reactive patterns.

What does that have to do with me? ;-)

What is the Qt equivalent of moving state outside of a QML component and both:

logging it when it changes rendering it inside two different compoments

?

Typically this involves creating a C++ object which holds the state, has properties and signals etc. This solves both of your points nicely and keeps UI and logic nicely separated.

@ples76 said in Can you create slots in main.cpp file?:

I have solved the problem with all of your help

Great, so please don't forget to mark your post as solved!

I am trying to find the easiest solution to this since I am under the gun to get this done asap

Although you find a solution now, you may want to take into account that having such a main() function is not a good idea as @Christian-Ehrlicher pointed out.
So time (and stakeholders) permitting, you might want to look at refactoring your code...

@SnuggleKat said in Difficulties connecting signals with slots (static members):

Just didn't know signals mustn't be defined...

If you mean "implemented" by "defined", then I wrote this in my first reply :)
Yes, you dont implement signals. You just set the signal signature in your header file. After that, you can emit your signal to notify connected classes (-> slots)

@JonnyQB
Hi
You declare it like
Punkte * punkten;

Then some place else you must do
punkten = new Punkte(); ( not in .h)
Often the constructor is a good place.

The problem was that my class inherited QGraphicsItem, not QObject, but I found another way to do what I wanted. From now on, I will use the new syntax. Thank you!

Hi @Md0ngo said in QThread signals|calls to QChart are blocking the GUI:

After so much time lost, solved it!!

It seemed to be the fault of the default QSeries implementation... Series.append() apparently emit a couple of signals and resize the inner vector which contain the QPoints. This combined to a O(kn²) loop totally messes up the main event loop.

It was "as easy" as refractoring the code so the thread builds up a QVector of QPoints, then signals each vector to the chart and it calls to series.replace() instead of append(), that is actually faster and lighter.

great that you were able to fix it yourself, and I learned something new and important about QCharts thank you ;-)

I was about to give up after trying the moveToThread way without success, but I was lucky enough to get the solution after finding this.

So, not a matter of Qthreads after all.. Now I'm wondering whether refracting the code to create a dedicated event-loop was worth it or not.

If an actual worker class is now replacing your infinite while loop, that you posted in the op, than yes it is, definitely!

Don't forget to set your topic to solved ;-)

@Kutyus said in QPushbuttons signals mismatch:

any solutions for multitouch handle?

Yes, use QML for your interface instead of QtWidgets

Depending on how complex things get, it might make sense to have a "data aggregation layer" between logic and UI. Basically, a UI element would only be connected to a single signal of the aggregation layer, and the aggregation layer would keep track of data changes, and would know when to emit that one signal.

It doesn't reduce complexity, but it cleanly distributes it between two parts of your program.

@seyed said in Signal not found at runtime:

So there MUST not be two class with equal name in the library and main app. did I understand correctly?

You can define the class in the library, and use it in the main app.

But you cannot define the class in both the library and the main app at the same time.

@mar0029 As @mrjj already said this is just wrong:

MainWindow *test = new MainWindow(this) connect(test->setupScreen, SIGNAL(sendSetupLocation(QString)), this, SLOT(receivedSetupLocation(QString)));

You create a NEW instance of MainWindow and connect its signal with the slot. You must use MainWindow instance that already exists. If your dialog is not created directly by MainWindow, but instead by another dialog then you can just pass the pointer to your MainWindow instance to the first dialog constructor which then pass it to the second dialog constructor.

Printing the variable which is set in a slot just after connecting the signal to the slot will just print its current value (empty string in this case)., because the slot was not called yet. If you call the slot directly with a not empty string then this string should be printed.

@SGaist

Thank you. That seemed to be the last missing piece. It does what I want now.

@Franz-Amador
No problem. If you've edited the Qt sources fixing the bug, and have the time, you could also submit that patch through the gerrit code review, although it requires some work to clone/setup the repository.

Kind regards.

@diredko Qt will output signal/slot problems on the console. Run your application from the console and you should see something like:

QObject::connect: No such slot QObject::movePiece(int, int, int, int)

Or something similar if there is an issue.

Also you can add a qDebug() << "Got here" to your connect() but like @SGaist said, you are connecting in a bad place. qDebugs() will show up on the console as well.

If you are in windows you will have to add CONFIG += console to your project file. Linux and OSX should be fine without.

And finally add qDebug() messages to your move and movePiece to see if it's getting in there.

Or of course you could use the debugger for all this. ;)

@Chris-Kawa yes that is an option, but what if erros appear while the processes running? If i put the MessageBox after the for-loop i need a mechanism to check if there was an error or not. therefore i wanted to use Signal and Slot for the process.

EDIT
i solved it. I wrote a function in which i check if there where errors with readAllStandardError and if the size of it is zero, no error appeared and the show the message box.

@JKSH Thanks for your help, May you help me more by writing a sample code for this ?

Thanks

@panch said:

Would you then restrict the signals/slots to only GUI-related information passing? As a proper way of developing Qt applications, I mean...

QNetworkAccessManager emits signals to tell the world that a download has completed. QSerialPort emits signals to tell the world that some data has been received. QMediaPlayer emits signals to tell the world that its playback status has changed.

These show that signals and slots are "proper" for developing all kinds of things, not just GUIs.

I figured it out. I needed to set my QObject and QCore stuff properly. In the .pro file of the shared library, I added:

QT += core

In the shared library's .h file, I switched this:

class CTSCANSHARED_EXPORT ctScan { public: ...blah blah...

with this:

class CTSCANSHARED_EXPORT ctScan: public QObject { Q_OBJECT public: ...blah blah...

And then ensured the shared library's .h file had this:

#include <QObject>

And then it compiled properly.