@texasRanger Why do you think you need an additional event loop? From your description I don't see any need for it. If file is changed you will get a signal from file watcher. You just need to make sure parsing of that file does not take too long.

Your code shows a lot of ignorance of how Qt works, as they point out, I recommend you read the docs urgently. Here no thread is necessary, it is only necessary to use the Qt event loop. Forget about sequential programming (Qt hates while true since they are not needed). You also do not know what the Qt signals are and how they are used. Also you do not understand the advantages and restrictions of threads, it is not safe to access and modify variables in different threads as you try to do.

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

Hi, Where do you get that ID ? You'll click on the action, get the ID and then call the slot ?

@Kalado said in Connect() uses wrong emitter object.: Look at some code: //A.h class task2 : public QWidget { Q_OBJECT public: task2(QWidget *parent = 0); ~task2(); protected: void mousePressEvent(QMouseEvent *event) override; signals: void myWidgetClicked(); //A.cpp void A::mousePressEvent(QMouseEvent *event){ /// use the respective classname emit myWidgetClicked(); } If ur using Classname as task2 , use void task2::mousePressEvent(QMouseEvent *event){ emit myWidgetClicked(); } Thanks,

difference between exec() and show(), Only QDialog have exec() Qwidgets have show. When you call show on a Dialog, it becomes visible but do not wait for input. example mainw::func() { MyDialog *dia=new MyDialog(this); dia->show(); int a=0; // this code is run the moment dialog is shown on screen, } using exec() mainw::func() { MyDialog dia; dia.exec(); int a=0; // this code is run only after dialog is dismissed. } The version of dialog where u call show() could be called floating so when user click ok it should emit signal that something should happen. ( to maiwindow ) The exec() version will report back the result ok/cancel/closed at once. learn when to use QObject, QWidget, QFrame QWidget is often used if making own widget. QFrame is used if you just need something to draw a frame. If you use Designer you can check out the Widgets that are available. QDialog is useful for any type of windows that pop ups up or open via a menu. I have to set anything inside Register. Yes, Register should be able to give the data back. the widgets inside are private so you need a function to return the data. You might also need to call http://doc.qt.io/qt-5/qdialog.html#accept in your Register buttons clicked slot.

@jsulm Thanks, I'll give it a try.

@VRonin Thanks for your input - there seem to be some misunderstanding. I can not and do not want to wait for the acknowledge of the server as a trigger to sent the next log message - this is against the idea. Log messages need always to be sent, regardless wether the server acknowledges or not - imagine the server even does not acknowledge. Every message sent has an ID# that is incremented by one for every new log message sent. The server acknowledges every message with returning the ID#. Looking at the network of the server with Wireshark and having incoming log messages with time stamps of the same msec - obviously the server has no time to send the acknowledge between incoming protocols. I.e. Sending #1 and # 2 in such a short sequence, obviously when sending #2 the counter for a missed message goes up to one. This is inherit by this system and is by design. Therefore, I'm going to implement a gap of at least a few msec between sending messages. Because the messages are all handled and forwarded in the application by signals / QtEvent queues, I dont have a solid idea so far how to do this. I may have to create a time gated sending queue before handing the messages over to the signal and the QtEvent queue.

@kshegunov said: the way the API is organized is a bit different from QTcpSocket You're right. I was also a little bit confused, when i used the QSerialBus module the first time (see my topic https://forum.qt.io/topic/65572/qmodbusmaster-example). Like i said, i think you can built your own class by inherit from QModbusDevice to have a synchronous API. The QSerialBus module is marked as technical preview in Qt 5.6, maybe they add some new functions in future releases similar to QTcpSocket like waitForConnected etc.

Hi, Thanks for your response. The whole body of code is proprietary so I'm not sure I can share it in a public forum. However I can make a note that it used to work fine a month ago and after that no changes occurred to this code and no qt libraries were replaced, so the issue is like to be caused by hardware malfunction. Thanks again ))

@mrjj Thanks :)

@mrjj Hi! I managed to make everything just as I wanted, everything is going fine. The code example you sent me really did the trick. Thanks a lot.

Hi, On a side note, there's no need to use fromStdString to initialize a QByteArray with a string.

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

Thx so much @kshegunov , I had Q_OBJECT in abstract class, but I forgot to put it as well in derived class. This solve my problem :) As a side note: I saw several times in the forums here that people are not declaring their overrides as virtual, this is syntactically correct, but I would suggest doing it (makes the code more readable) or even better is to use C++11's override specifier. Thx for this tip so much, I like this kind of notes which helps me improve the code. Yeah you're ride it looks more readable right now :) Parent public slots: virtual void itemToAdd(AbstractFood* item)=0; Child: public slots: void itemToAdd(AbstractFood* item) override; void pizzaToCustomize(Pizza *pizza); and we exactly know what was overriden from parent. Many thx

@SGaist you are right, I was not receiving anything from qml so my container was empty.

Not every member function needs to be a slot. If it produces some value it doesn't sound very slottish. Consider you have a slot like QByteArray MyClass::saveData() and you connect it to some button: connect(button, &QPushButton::clicked, myObject, &MyClass::saveData). You can connect it that way but where would the byte array data go? Button is certainly not gonna do anything with it. Instead something like this seems more reasonable: class MyClass { ... public slots: //could be private or whatever void processPictureData() { savePictureData(loadPictureData()); } void savePictureData(const QByteArray& data) { /* write the data to some storage thing place */ } public: //could be private or whatever, but it's not a slot QByteArray loadPictureData() { // it could even be made static member to allow greater reusability /* do what you did and return the data */ } } Now you have a nice modular design, each piece of functionality reusable in isolation and hermetic. You can connect either of the slots to some signal. Btw. as the help in the footer suggests please use ``` around your code, not @.

Hi, Fortunately for you Qt is very intuitive that way : you just have to implement the resizeEvent method.

Are you sure the signal isn't getting emitted or is it a getting emitted but the sendmail object isn't picking it up? My guess is your send mail object is doing something (locked up and never going back to the event loop). So it is never receiving that second message since it never gets back to the event loop. Don't know for sure without seeing the code for it, but just something I've noticed in thread programming with Qt. You could gdb to break into the application and see what your thread is doing. If it isn't in processEvents() that is probably the issue. Oh and one more thing, you can easily test the emitter by create a fake sendmail object with that same slot, then just have it write to the console when it sees that signal. That way you know if is doing nothing but writing to the console and exiting the slot so there won't be any hang ups. My guess is it will work and that your problem lies in the sendmail object. [edit]: added more ideas :)

Since you switched to QSqlTableModel, are you using it's functions to add new rows ?

Hi, Short answer: no The slot signature must either have the same number or less parameters than the signal and the type must be the same.

Qt developers have investigated this before, and there is a partially-working patch. There are still a number of important challenges to work through, but devs are focussing on other things at the moment. It is not currently being actively worked on: http://comments.gmane.org/gmane.comp.lib.qt.devel/10327

Thank you, I had a bit of a read around signal mappers and they seem like the perfect tool for what I need.

Hi sneubert, No I had forgotten to add that.

@SGaist Thanks. Now I have a more clear picture about signals.

What's weird is I tried the same code again today, but I'm getting the sender this time. Something is not right with how PySide passes the sender, but I can tell this is one of those bugs that will be really hard to track down since it's really inconsistent. Here's a simplified version of what I'm working with: import sys from PySide.QtCore import * from PySide.QtGui import * class CustomDialog(QDialog): def __init__(self, parent=None): super(CustomDialog, self).__init__(parent) self.setLayout(QVBoxLayout()) self.table = QTableWidget() self.table.setColumnCount(2) self.layout().addWidget(self.table) self.table.setRowCount(10) for row in xrange(self.table.rowCount()): item = QTableWidgetItem(str(row)) self.table.setItem(row, 0, item) combo = QComboBox() combo.addItems(['one', 'two', 'three']) combo.currentIndexChanged.connect(self.onIndexChanged) self.table.setCellWidget(row, 1, combo) @Slot(int) def onIndexChanged(self, index): print self.sender() def main(): app = QApplication(sys.argv) dialog = CustomDialog() dialog.show() app.exec_() if __name__ == '__main__': main() If you don't get the bug, I wouldn't spend too much time looking into it, but I appreciate the help.

As @Dyami-Caliri said your program is not using the thread at all. You are calling both generateCoordinates() and repaint() in the ui thread. There's no parallel execution here.

Hi, Tabs are lazily loaded. Have you made sure it is loaded already when you expect the signal ? See following example: import QtQuick 2.4 import QtQuick.Controls 1.1 Rectangle { width: 200 height: 200 visible: true Button { id: button z:1 anchors.bottom: parent.bottom anchors.right: parent.right text: "Press Me" } TabView { id: tabview anchors.fill: parent Tab { title: "Tab1" } Tab { title: "Tab2" Connections { target: button onClicked: console.log("Button Pressed") } } } }

Yes that was it. You slot looks good. For that second task you can use QSignalMapper)

I could connect by changing the target of Connections dynamically in loader.