Some odd statements in a QML project

[tomy]

Hi all,

Please take a look at this example.

What does onTextChanged: backend.userName = text in the TextField mean in the main.qml file?

The backend.userName is a function not lvalue to set the text onto it!

[J.Hilk]

@tomy
actully, when you look at the cpp class, you‘ll see that it‘s a function and the name of a property as well.

the part in qml accesses the property, and therfore invokes the setter function and not the getter function, which happens to have the same name as the property.

[tomy]

@J.Hilk
Thank you.

and therfore invokes the setter function and not the getter function

Why does it invoke the setter function (setUserName)? Is it because that property is used as a left hand value and something is to be written on it and in the property definition we have set that setter to be called in situations like this? ...WRITE setUserName ...

[J.Hilk]

@tomy in a nutshell, yes 😉

[tomy]

@J.Hilk

Thank you dear Hilk. (Where do you get those imojies from?! hhhh ◉_◉)

And, the correct use of C++ in QML apps generally is what the link says, yes?
The most common and quickest way to do this is to expose the C++ class to the QML runtime, provided the C++ implementation is derived from QObject.

And by "to expose the C++ class to the QML runtime" he simply means that cpp class register inside main.cpp as a QML type, right?

The third question for you is: I want to use the signal the way the link mentions. That is, inside main.qml, I write onUserNameChanged, but the error "invalid property name" appears! :( How to put it correctly into practice?

Please let me ask my fourth question too. (^-^)
Is the real equivalent of Qt connections (signal-slot) the signalName & onSignalName mechanism in QML?

[J.Hilk]

@tomy

Thank you dear Hilk. (Where do you get those imojies from?! hhhh ◉_◉)

cmd + ctrl + spacebar ->
as far as I know a Mac feature only.

The most common and quickest way to do this is to expose the C++ class to the QML runtime, provided the C++ implementation is derived from QObject.
And by "to expose the C++ class to the QML runtime" he simply means that cpp class register inside main.cpp as a QML type, right?

Yes, either as context property, created in c++ and exposed to qml.
As a c++ las than can be created locally inside a qml file
Or as a singleton, if you want to combine the above 2

The third question for you is: I want to use the signal the way the link mentions. That is, inside main.qml, I write onUserNameChanged, but the error "invalid property name" appears! :( How to put it correctly into practice?

hard to tell, can you show some code?

Is the real equivalent of Qt connections (signal-slot) the signalName & onSignalName mechanism in QML?

yes and no,
onPropertyChanged equals the slot that is connected to the signal, true enough,
but there's also QML Connections

[tomy]

@J.Hilk

As a c++ las than can be created locally inside a qml file

What please? I didn't get this part.

Or as a singleton, if you want to combine the above 2

If I figure out the above one then will go to study this one too. :)

I'm rather confused by how many ways we can use C++ in QML. I think the best way is to use C++ as the back-end and QML as the front-end part, like the example above.

can you show some code?

[J.Hilk]

@tomy said in Some odd statements in a QML project:

As a c++ las than can be created locally inside a qml file

I'm talking about qmlRegisterType that allows you to expose a c++ class to qml and you than can create instances of it inside your qml

There's qmlRegisterSingletonType that allowes for one single instance to be shared across c++ and qml (intanciated in qml the same way as the point prior)

and there's https://doc.qt.io/qt-5/qqmlcontext.html#setContextProperty that is a (in)c++ (created) instance exposed to your qml engine and can than be accessed from all qml files as a "global pointer"

the userName property is part of BackEnd but you try to listen to it inside ApplicationWindow that won't work

This 2 ways should work:

BackEnd{
    id:backend
    onUserNameChanged: console.log("Username changed", userName)
}

or

//anywhere in your main.qml
Connections{
    target: backend
    onUserNameChanged: console.log("Username changed", userName)
}

[tomy]

@J.Hilk

Thank you for your explanations.
I tried to know all three types of using C++ in QML and went for Docs. As usual, rather bewildering! :( Your explanations were much better.

1- qmlRegisterType: instantiated and used in QML. As a C++ class we can have instances of it not only in QML files but also in another C++ file in that project. Right?

2- qmlRegisterSingletonType: For specific uses when we only need one single instance of the cpp class to also be shared for both C++ side and qml as well. Right?

3- ContextProperty: We use it when we want an instance a class, defined in cpp, to be used globally in both cpp and QML sides. Right?

[tomy]

@J-Hilk

actully, when you look at the cpp class, you‘ll see that it‘s a function and the name of a property as well.
the part in qml accesses the property, and therfore invokes the setter function and not the getter function, which happens to have the same name as the property.

They both "must" have the same name because in the property arguments, they are pointed to for write and read functions. Agree?

Also, in Q_PROPERTY(QString userName READ userName WRITE setUserName NOTIFY userNameChanged) where is that first argument "username" (of type QString) used in the project, please?

[J.Hilk]

@tomy said in Some odd statements in a QML project:

@J.Hilk

Thank you for your explanations.
I tried to know all three types of using C++ in QML and went for Docs. As usual, rather bewildering! :( Your explanations were much better.

1- qmlRegisterType: instantiated and used in QML. As a C++ class we can have instances of it not only in QML files but also in another C++ file in that project. Right?

2- qmlRegisterSingletonType: For specific uses when we only need one single instance of the cpp class to also be shared for both C++ side and qml as well. Right?

3- ContextProperty: We use it when we want an instance a class, defined in cpp, to be used globally in both cpp and QML sides. Right?

yes, on all cases

They both "must" have the same name because in the property arguments, they are pointed to for write and read functions. Agree?

Also, in Q_PROPERTY(QString userName READ userName WRITE setUserName NOTIFY userNameChanged) where is that first argument "username" (of type QString) used in the project, please?

QString userName defines the property type, (QString) and the name you have to use in qml to access it userName . In this case the name for the qml property has the same name as the READ function

[tomy]

@J.Hilk
Very good. I changed that and now it's more clear.
Thanks. :)

[fcarney]

@tomy said in Some odd statements in a QML project:

Thank you dear Hilk. (Where do you get those imojies from?! hhhh ◉_◉)

If your running Linux: emoji

[tomy]

@fcarney
Windows! :(
But thanks for your attention.

[JKSH]

@tomy said in Some odd statements in a QML project:

Windows! :(

https://blogs.windows.com/windowsexperience/2018/02/05/windows-10-tip-get-started-emoji-keyboard-shortcut/

Or, search Emojipedia and then copy + paste: https://emojipedia.org/search/?q=laughing

[tomy]

@JKSH
Thanks.
With this nice gift, it's time to close the thread and mark it solved. 🙂