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

The export (or lack thereof) definitely was the problem. Once I got in this morning and cleaned up by code a little and rebuilt everything the export is now working fine. I must have had an old build of something that wasn't getting cleaned. Anyway thanks for the help!

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

@JohanSolo Thanks for the suggestion. I had done some reading about blockSignals() but I went back and looked again. The problem with blockSignals() is that it still leaves me needing to know that I wanted to emit a particular signal but couldn't. I somehow need to know how to re-emit the signal later when the server interaction completes. An event filter would almost work. I could add a filter for my QState objects. In that case what comes to the eventFilter() method is a QSignalEvent. If I could detect in the filter that my server operation was in progress, then I could save away the event (or the event parameters) then use them to post the event equivalent of the original signal at the correct time. I could dynamic cast the event pointer and even peel off the arguments, but there does not appear to be any public constructor for a QStateMachine::SignalEvent, so I have no way to reconstruct a copy of the original event. I also looked at using QAbstractTransition or QSignalTransition, but those basically have the same problem. There's no way to store the event to use later.

Thanks! I fix the problem. All works fine, but I have a Rectangle over that hide the window background and that was the problem.