Return QObject undefined

[wysota]

Looking at the output you can see it is cast as a QVariant when the signaled using Object1 *.

What does the following mean? If that's an example of clear description of a problem then it's likely we understand differently what "clear" is.

QVariant(Object1*)
undefined
Object1(name = "")
object1 name property
Object2(0x17392c0)

[coderbob]

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.

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.

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.

QVariant(Object1*)
undefined

That is the output when passed as a defined type

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.

Object1(name = "")
object1 name property

That is the output when passed as a QObject

function displayObject(obj1)
{
 print(obj1);
 print(obj1.name);
}

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.

[wysota]

I am at a loss as to what to say wysota. The code cannot become much simpler

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.

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

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.

it will be cast as a QVariant with no way to access its 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:

Object1* argToObject1(QVariant v) {
  if(!v.canConvert<QObject*>()) return 0;
  QObject *o = v.convert<QObject*>();
  return qobject_cast<Object1*>(o);
}

Object1* argToObject1(QVariant v) {
  if(!v.canConvert<QObject*>()) return 0;
  QObject *o = v.convert<QObject*>();
  return qobject_cast<Object1*>(o);
}

To copy to clipboard, switch view to plain text mode 

The SAME EXACT OBJECT is being passed to the function and should be casted the same.

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.

This is the whole reason behind inheriting QObject and the meta system.

And that's the only thing that makes this problematic.

The output is as clear as day, I am not sure how this is not making sense to you.

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.