On 29.05.2012 10:55, Rene Jensen wrote: >>> Question: How can we expose objects governed by QSharedPointer to >>> QML >>> safely? I *can* guarantee the lifecycle beyond the life of my >>> QDeclarativeEngine. >> If you can guarantee that, then use mySharedPtr.data() as others >> have >> said. > > Just a quick thought, would that suggesion be leading into trouble? > In > only see one way to do that right: > > Step 1: mySharedPtr.data() ==> MyShared* P; > Step 2: make sure the QML engine doesn't assume ownership: > QDeclarativeEngine::setObjectOwnership > Step 3: hand over P to QML: setProperty or setContextProperty
Yep, those steps seem to be the current requirement. If my patches get in (not guaranteed), it will be reduced to just: Step 1: setContextProperty("myname", mySharedPtr); or Step 1: setContextProperty("myname", mySharedPtr.toWeakRef()); depending on your needs. > > When I said the database layer should preferably remain QML agnostic, > I merely wanted to keep "patchup code" like "setObjectOwnership" out > of a clean set of data classes for purist reasons. (Really it is an > exaggeration imho.. I have no problem using stuff from QtDeclarative > in code. Will need it for QList properties anyway. It's just a design > reflex). Yes, I agree. > Leaving out step 2 is bad, right? Yes, and worse it might not obvious to consumers of the API that it's needed. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development