Den 10-01-2016 kl. 03:21 skrev mark diener:
Hello List:I have a couple of core QMLEngine questions: Basic Code Snippet: QQmlEngine geng ; QQmlComponent gcomp(&geng) gcomp.setData( ByteArrayofQML , QUrl() ) ; gcomp.create() -> Show the QML in the QML Engine if (gcomp.isError() == false) -> we have visible QML! 1) How does one cause all properties in the root context for QML engine be triggered to re-evaluate their bindings again. For example Text { text: gvariable }, it want text object to re-fetch its own values instead of pushing values with Qobject->setProperty(). Generic pull instead of specific push. Can I cause a disturbance in the QmlContext and that would trigger and "expensive" refetching of text values for example.
On one hand, this question doesn't make sense. QML vars are considered changed immediately, and that's a basic design choice.
OTOH, it's very simple to do this yourself. Just create a function that pulls in the new variable values. You might need a proxy object between the real value place and the QML land, but other than that you need no tricks for it.
2) How does one clear out everything loaded in the root QmlEngine context? What is the best way to clear the root context of qmlengine of everything prior to calling gcomp->setData() and gcomp->create( ) to load brand new QML into the QmlEngine? geng->clearComponentCache() ? Does this really flush everything out regardless of anything that is currently visible on-screen? I do not want to build up a pile of QObjects in the engine, I want them cleanly flushed out.
Again, there are ways you could do this. Store the set of accepted vars and values and reset to exactly those when you want, for example.
But this idea smells badly of a fundamentally bad design. If you need to get rid of variables, reset them, etc. then they probably shouldn't be stored as context on the root engine. This sounds like one of the "how do I do B" because you are doing "A" already questions, and the problem is that "A" is wrong. We get those on this list all the time.
One idea I have used often is to have a backend object that is almost the only object exposed to QML. Inside this one you can set variables on the fly as you want. With the very limited amount of info you have given here this seems like a much more appropriate direction for you.
Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
