Hi,

Do you mean get additional data using QSqlQuery ?

OK, found that there are two sides for that coin as well.
I need to check the other side as well as one sees in the mutlicast sender example.

@richardo I appreciate your input. Still I'm not sure I really like this approach that much better.

As for the cycle, I couldn't see any of those usual cyclic property warnings that QML gives you in those cases. I think this cycle is already properly broken by using the correct construction in setMyCppValue:

void setMyCppValue(int newValue) { if (newValue!=myCppValue) { myCppValue = newValue; emit myCppValueChanged(); } }

@xtingray

This helped a bunch, I got it to work !!!!

Thanks you sir for your time,

Duncan

Hi,

@flashmozzg said:

The problem is that MyCustomItem contained property with the same name in itself

This is called variable shadowing.

this is really counter-intuitive. What if it wasn't my item but someone else's and I didn't know that it had such property?

Idieally, that someone else would document all the properties of the component, and you would read the documentation before using their component.

But to avoid ambiguities, I suggest always specifying the owner whenever you refer to a property that isn't part of the current component, e.g.

MyCustomItem { id: myId visible: parent.isExpanded // other stuff }

qt creator could've at least warned about possible ambiguities.

That could be a useful feature in Debug mode. You can submit a feature request to https://bugreports.qt.io/ if you wish.

I don't want this to be enabled in Release mode though, because it would degrade the performance of the QML engine.

So you assume the measurements are wrong? Can you try with a better tool, like Wireshark? This shows you single packets and all details.