QDeclarativeEngine::setObjectOwnership (this, QDeclarativeEngine::CppOwnership);
We also had to implement reference counting because we shared our list
objects throughout the program.
> _______________________________________________
> Qt-qml mailing list
> Qt-...@qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-qml
>
>
_______________________________________________
Qt-qml mailing list
Qt-...@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-qml
I've found that using the latter is easy to get started, maybe for
throwing a PoC or something, but if you really want to use model in QML
from C++, it's worth implementing it with a QAbstractListModel. In the
end it's not even that much more code.
Or was there a reason the model had to be a QList<QObject *> thingy?
Cheers,
Johan
I am trying to get access to some global objects from a QML WorkerScript, and whatever I do I cannot seem to access them. The key object is a C++ object that implements a time consuming function, so I thought this might be the way to go.
The first attempt was to pass the object as inside the workscript message:
MyQml.qml:
Player {
id: player
}
WorkerScript {
id: workerThread
source: "qrc:player.js"
}
workThread.sendMessage( { object: player } );
This did not work - the message.object is not an object.
The second attempt, declare global variables inside the JavaScript file:
player.js:
var myplayer;
MyQml:
import "player.js" as Player
....
Player.myplayer = player
workThread.sendMessage( {} );
The WorkScript.onMessage function cannot access player.
I am sure that I have missed some crucial piece of documentation somewhere, but any help solving this issue would help.
Ronan.
On Mon, Oct 10, 2011 at 5:50 PM, <ronan.ma...@nokia.com> wrote:
> Player.myplayer = player
> workThread.sendMessage( {} );
>
> The WorkScript.onMessage function cannot access player.
>
> I am sure that I have missed some crucial piece of documentation somewhere, but any help solving this issue would help.
>
In http://doc.qt.nokia.com/4.7-snapshot/qml-workerscript.html#sendMessage-method
, it is said:
"The message object may only contain values of the following types:
boolean, number, string
JavaScript objects and arrays
ListModel objects (any other type of QObject* is not allowed)
All objects and arrays are copied to the message. With the exception
of ListModel objects, any modifications by the other thread to an
object passed in message will not be reflected in the original
object."
Could this be causing your problems? I have no experience myself with
WorkerScript, however I know from other similar systems there is quite
some constraints on the "messages" you can pass as objects to other
context to be run in parallel...
If this is not the issue, I will be also quite curious to know how to
do something like this, how to pass the instances properly for
processing, consider Python's Queue.Queue module and multiprocessing.
-Sivan
Hope this helps and that it is correct :)
-Sivan
--
The JS file looks something like this:
.pragma library
var globalObject;
function getGlobalObject() {
return globalObject;
}
function setGlobalObject(object) {
return globalObject;
}
In each QML file, you import this one and then you have access to your
object.
I think this is a horrible piece of code, but it's the only way I have
found so far.
If possible, move the shared values you have to a C++ object instead and
declare this as a named global property. This is a cleaner way to access
shared values. But it only works on limited data types.
Bo.
Bo Thorsen,
Fionia Software.
--
Expert Qt and C++ developer for hire
Contact me if you need expert Qt help
http://www.fioniasoftware.dk
If you declare your object to be well, through the source location,
global, and using .pragma then why do you need the functions to access
it? Also, does you approach allows passing the whole object including
methods (so you can manipulate them for instance) as opposed to just
passing values and responses as strings as noted in WorkerScript qt
docs?
> In each QML file, you import this one and then you have access to your
> object.
>
> I think this is a horrible piece of code, but it's the only way I have
> found so far.
>
> If possible, move the shared values you have to a C++ object instead and
> declare this as a named global property. This is a cleaner way to access
> shared values. But it only works on limited data types.
I was sure that due to the nature of objects serialization in JS, this
would actually be the only way to pass all of the types to the worker
script?
Thanks for the note!
-Sivan