Maybe that thread needs a QEventloop instance and a call to it's exec function to properly send off those invokeMethods.

@SGaist Thanks again for your reply, it really gave me the key to know what was going on. The problem was that the Connections were defined in a component that was continuously being created and destroyed, as it is part of a StackView. With this behaviour, every time the component was created, a new connection was defined. Moving the connections to a general component solves the problem.

Thank you very much! :)

No particular restrictions. As written before, QObject based classes are usually declared in their own header. Nothing prevents you from having them in a cpp file, you just have to put the corresponding include at the end so they are also parsed by moc for QObject based classes in them.

Hi,

Out of curiosity, why do you want to "simulate" a button click ?

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

@Mathan-M
as i said when it displays a row, the model is correctly applied, so there must be something wrong with your model implementation.

@Mathan-M said in Signal emit Issue - Listview is not showing full list:

Do we have any link/tutorials to follow or how to bind the value from CPP to qml.

Here you go.

@mrjj Thank you!
Sooo i kind of did what you said and used the currentIndexChanged signal. I made a Qbytearray where i store the currentindex and replace the index when an index changed. Then i can use this array to get the currentIndex from the row where the button was pressed. I know that there is probably a better solution but it works^^
I will mark this post as answered i guess.

@namit
ok super.

Since it's a QObject you can use the parent/child paradigm to let Qt handle the deletion for you.

Do you get any messages about slots/signals when connecting?(what I mean is "no such slot/signal")

@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()