[4.7] QML properties load order

bunjee

Hey guys,

Is there a way to specify the "first load" order for QML properties.

For instance:

@Item {
loadMeFirst: 1

 width: 200
 height: 200

}@

When calling create QDeclarativeComponent::create(QDeclarativeContext * context = 0), I want "setLoadMeFirst" to be called before "setWidth" and "setHeight".

Thanks.

mbrasser

In general there isn't really a way to do this (part of being 'declarative' is that ordering of assignments shouldn't usually matter). Can you say any more about why you would like to do this? Is it for a custom C++ component (in which case deriving from QDeclarativeParserStatus might be helpful)?

That said, you might be able to exploit the engines overall ordering to achieve what you are after:

Literal assignments are performed first
Bindings are evaluated next
Component.onCompleted is called

For example, forcing width/height to be a binding should cause loadMeFirst to be assigned first (assuming these trivial bindings aren't optimized away to literal assignments):
@Item {
loadMeFirst: 1

 width: {200}
 height: {200}

}@

bunjee

Thanks mbrasser.

I'm trying to do an "Application" C++ QML object and a property that contains plugins to be loaded at runtime.

Obviously I need to load the plugins before anything else. Guess if QML does not allow this I might do a "pluginspec" file.

mbrasser

Hi,

Have you looked at "QDeclarativeParserStatus":http://doc.qt.nokia.com/4.7/qdeclarativeparserstatus.html at all? Many of the built in visual items use this to delay doing any "real work" until all of the properties have been set (at which point componentComplete() is called). You might similarly be able to avoid doing anything requiring the plugins until componentComplete() is called.

Michael

bunjee

@mbrasser : Yep I've looked at QDeclarativeParserStatus.

My QML Object I'm trying to operate with is a QObject not a QDeclarativeItem.

So I guess it complicates things a little bit ? Or maybe I missed something ?

mbrasser

Hi,

Working with a direct QObject-derived subclass rather than a QDeclarativeItem-derived subclass shouldn't be a problem (the engine itself knows nothing about QDeclarativeItem; to the engine QDeclarativeItem is simply another QObject with properties). Note that QDeclarativeParserStatus is an interface that is meant to be multiply inherited from (i.e. you would inherit from both QObject and QDeclarativeParserStatus to use it).

Regards,
Michael