Well... if you want it done right do it yourself XD Obviously, Qt has it's pedigree and Qt Bindable Properties are impressive in their own right, and I would never claim to be better than a team of veteran professionals; but, in this one case this (and a few other) quirk(s) of Qt Bindable Properties ended up bothering me enough that I decided to go nuts and take a stab at them myself. Although my system doesn't have quite the same level of polish as Qt's, I'm very satisfied with how they turned out. So, if it happens that any one else: Doesn't need QML integration (i.e. C++ properties only) Doesn't need to access properties abstractly through the meta-object system and Wants their binding evaluations to only ever run once per-update and never read stale values, such that the evaluation of the above example is always: 1) pStruct 2) pEmpty 3) pHello with almost the same API, feel free to partake in my experiment :) Qx Bindable Properties There's an easier to follow example in the documentation for this above under "Advantages".

@ian28 the way you are doing it is how one would implement a new QML component in C++ that would tend to be purely used in QML - i.e. you wouldn't normally interact with it from the C++ side once it is created. If you wanted to continue with that sort of approach, it might be better to create the timer in QML and have that update the path of your Image. However a better fit might be to expose your "model" via a "singleton instance" (see qmlRegisterSingletonInstance). This is the more modern approach that is advised rather than using the older setContextProperty, but you will probably find more information out there about using setContextProperty. It's not massively different in principle and it might be easier for you to use the older approach in order to get started.

@Tom-asso said in Access read-only C++ property from QML: Here is my QML: ApplicationWindow { [...] property string testString: SharedConstants.testString Component.onCompleted: {console.log("onCompleted"); console.log("testString: ", testString)} But I will be adding other stuff to SharedConstants (e.g. enum) so I must actually register SharedConstants (as described here) in main.cpp: // Register SharedConstants so QML can access its properties qmlRegisterType<SharedConstants>("SharedConstants", 1, 0, "SharedConstants"); Debugging shows that the designated C++ accessor function getTestString() is not invoked either. What am I doing wrong here? qmlRegisterType registers an instantiable type, but the QML code above attempts to use it as a singleton. Either instantiate an instance of the type in QML, or use one of the singleton registration methods such as QML_SINGLETON, qmlRegisterSingletonInstance, or qmlRegisterSingletonType.

@Christian-Ehrlicher Thank you for your advice. The sample code has been added to the bug report.

Thanks, I found examples for JS here.

@b-arun-kumar said in Order of QML property's dependency evaluation: Response from Qt Support: As per this old article: https://www.kdab.com/qml-engine-internals-part-2-bindings/, static value assignments happen during creation phase and binding value assignments happen at the end of creation phase. That is how it should be, literals first, then functions. But it is not actually documented so in theory it could change. This is also only true for simple literal assignments. Anything even slightly hinting about complexity makes QML engine postpone them together with all those needing the evaluation. For example it happens if you wrap the value with {} like this: p2: {true} Case 1: CustomQMLComponent{} In this case, based on the above article, p1 & p2 values are set by the time p3 value is set. The order in which these "static" properties are set is undefined and also the order in which more complex expressions are done are undefined. So it is best to avoid making assumptions about the order. Case 2: CustomQMLComponent{ p1: "my_string" p2: true } What happens in this case? In a more general sense, what happens when properties of a component are set when creating an instance of the component? Are the properties initialized with default values and then overridden by the new instance's values? Or, the properties are initialized just once with the default/new values. Just once. Although the properties do of course have some default value before the value in QML is assigned. The initial value set in constructor of a C++ class, or in case of QML defined property, default constructed value of the type (empty string, 0, false or null in case it is QObject* type). And why this could be important is because something like onXXXChanged signals are handled immediately when they occur and thus it could be ran before all those "static" assignment are done. Consider for example: onP1Changed: if (p2) {...} else {...} QML engine does not know that there is some dependency to p2 on p1 value change and in case p1 gets assigned before p2, this could take unexpected path and if p2 value change is not explicitly also handled properly in this case, could lead to mismatched state.

@GrecKo said in Is it safe to bind to C++ subobject's property in QML?: But why don't you do property var qmlCompProp: database.getDbpointObject() in yout qmlComp? prop1 and prop2 are passed to the database.getDbpointObject(prop1, prop2) function. prop1 and prop2 are properties of qmlComp. These properties are set when an instance of qmlComp is created. Item { required property string prop1 property bool prop2: false property var qmlCompProp: ({}) Component.onCompleted: { qmlCompProp = database.getDbpointObject(prop1, prop2) } } Since the properties evaluation order is undefined, and qmlCompProp depends on both prop1 and prop2 values, I've opted to initialize qmlCompProp with an empty object and assign the actual object in Component.onCompleted. Is this the right/recommended way, or is there a better way to handle this? Thanks for the information about the warning and it's workaround.

Then maybe something like the json based plugin metadata used by Qt and Qt Creator.

@TripleF Awesome, this works! Thank you

@stan.m The root cause was a thread-safety problem; data was read by the main thread at the same time that it was written by another thread. Specifically, the C++ getter for the QString "value" property was called at the same time that the value was written. Other data was written and read at the same time, but their types write as an atomic operation on the ARM processor. The data that caused the problem was of type: QString. A QString object's member data is a heap pointer to the 16-bit unicode array. When written and read simultaneously, the C++ getter passes a corrupted pointer into the QML runtime. As I wrote before, the "binding loop" warning came after many of these "first-chance" exceptions and had nothing to do with a true binding loop. The first-chance exception occurred when two value changes occurred back-to-back and the QML runtime called the C++ getter to retrieve the value at the same time that the second change was written. My initial "fix" worked because polling the value every 100ms allowed the first change propagate to QML long before the next change comes in. I since have revised the code to use a mutex to prevent writing and reading simultaneously.

@sierdzio Thanks for your input! The this-object was the parent widget holding the QQuickView. I solved it by saving the root object of the QQuickView: QObject *obj = quickview->rootObject(); if (obj) obj->setProperty("ticks", tick_count); else qDebug() << "Could not set tick count!"; Anyway, I'll have a look at the different approach you suggest. It sound like a more robust way of interacting with QML. Best regards, E

ok. Let us look at like this. Instead of web view, put the Rectangle{} Try to show & hide the rectangle instead of web-view. Till me whether it works or not. Try something like this OffLine_Pages.qml Pane{ id: view property string local_url : "" property string pid : "" property alias vis: web.visible Rectangle{ id : web width: 200;height: 200;color: "red" visible: false } }

@GrecKo said in Binding C++ properties exposed to QML to dynamically created QML objects: Ultimately I think that you should use imperative object creation only for temporary object needed by the UI layer, like showing a dialog for example. I have yet to see another legit usecase for it (or I don't remember it). I will keep this in mind! Hopefully this little discusion might help someone else struggling to understand the same concepts!

@raven-worx: Yes, it's ambiguous because I don't know (or there isn't) a syntax for disambiguating. For example in C++ a roughly equivalent statement, involving a local text and a global text, would be text = ::text which is unambiguous. Hehe, I was discussing that with others last week, a way to differentiate context properties from regular object properties. Could be used in your case to disambiguate the root context property, or to access model properties from outside a delegate, for example : listView.currentItem::age without having to expose it as a property. This syntax is not achievable for the moment, but you could do something like this listView.currentItem.Context.property("age"), you won't get notified of any change though. You could also do it for the root context with a singleton exposing it with the same caveat about the changes.

Hi, Take a look at the MEMBER element of the Q_PROPERTY declaration here. It likely does what you want. Hope it helps

@Kofr Hi! If you want to be really sure (because you don't trust the docs or your code ^_^) then add something like qDebug() << "hello"; to the destructor of the model and see how often that's called.

Got it solved :-) QWebFrame * webGUIframe = qobject_cast<QWebFrame >(sender()); QWebView * webGUI = (QWebView)(webGUIframe->parent())->parent(); webGUI->page()->mainFrame()->addToJavaScriptWindowObject("NativeBridge", this);

@Wilk it's cool! What about JSON serialization? I will try to use your library in my project http://forum.qt.io/topic/64999/qt-micro-rest-client-framework-beta