I am at a loss as to what to say wysota. The code cannot become much simpler and I am not sure how to phrase this so you can understand it. I will attempt one last time and then I will just leave it to the trolls since it has already been addressed as a known issue to be resolved.
If this is true then please explain why when a class that inherits QObject is passed by defined type you cannot access any properties in QML/JS (The code example clearly shows this) it will be cast as a QVariant with no way to access its properties in QML/JS.Sure there is. All custom things in Qt go through QVariant and signals and slots use QVariant as means for data storage with queued connections.
That is the output when passed as a defined typeQVariant(Object1*)
undefined
If this SAME OBJECT is passed in a signal/slot but is passed as a QOBJECT instead of it's defined type it will be casted correctly and the name PROPERTY will be accessible in the QML/JS code.
That is the output when passed as a QObjectObject1(name = "")
object1 name property
Qt Code:
function displayObject(obj1) { print(obj1); print(obj1.name); }To copy to clipboard, switch view to plain text mode
All that does it attempt to access the property of object signaled. The only difference is how the signal is formated. The SAME EXACT OBJECT is being passed to the function and should be casted the same. This is the whole reason behind inheriting QObject and the meta system.
The output is as clear as day, I am not sure how this is not making sense to you.
All the code example does is pass the same object twice to the QML code which executes a script that attempts to read the name property of the object passed to it. In one case it is casted correctly and in the other it is casted as a QVARIANT. When it is casted as a QVARIANT the name property is not readable by the script code. This is the two seperate outputs you quoted. If you run the program look at the console window this is where the output is going.
You are saying it must be made known to the signal/slot mechanism. If this is true then please explain how a class that inherits QObject is made known to this mechanism.
Of course it can become much simpler. You only need to show three statements in three different situations and it doesn't require a bunch of files and having to click some area in a window.
That's simple - because the scripting environment doesn't know your QObject subclass is really a QObject subclass so it doesn't try to extract the proper type from QVariant. This is a deficiency of QScriptEngine or QVariant, I guess.If this is true then please explain why when a class that inherits QObject is passed by defined type you cannot access any properties in QML/JS
There is a trivial way to access your properties. Simply export a method that will perform the conversion in C++. Something like:it will be cast as a QVariant with no way to access its properties in QML/JS.
Qt Code:
if(!v.canConvert<QObject*>()) return 0; return qobject_cast<Object1*>(o); }To copy to clipboard, switch view to plain text mode
Well... "it depends". According to javascript you can never rely on the type of arguments passed to a function, it's not a strongly-typed language.The SAME EXACT OBJECT is being passed to the function and should be casted the same.
And that's the only thing that makes this problematic.This is the whole reason behind inheriting QObject and the meta system.
It's not that it doesn't make sense - I can analyze code and understand it but if you are providing a potential bug sample, you shouldn't force anyone to have to analyze your code for half an hour each time like I had to be doing from the very beginning of this thread. In my opinion if something is larger than 30 LOC, it's not a test-case anymore.The output is as clear as day, I am not sure how this is not making sense to you.
Bookmarks