How to bind TextInput.text to QString property in two ways?

mbrasser

Hi,

QML currently only supports "one-way" bindings. You can use the "Binding":http://doc.qt.nokia.com/4.7/qml-binding.html element if you want to bind lineEdit.text to the text of the TextInput as well.

@
import Qt 4.7
Rectangle {
width: 240
height: 320

TextInput {
    id: input
    text: lineEdit.text
    anchors.fill: parent
}
Binding {
    target: lineEdit
    property: "text"
    value: input.text
}

}
@

Regards,
Michael

axeljaeger

Thank you. This is exactly the information I was looking for.

njeisecke

Hi,

Doing this will generate a console warning:

QML TextInput: Binding loop detected for property "text"

It works nevertheless but I don't like warnings.

Any ideas?

Regards

Nils

andre

File a bugreport :-)

njeisecke

Well, it actually is a binding loop. However it does not do any harm as long as the setter on the C++ side is implemented correctly.

andre

I meant it more as: file a bug report with a suggestion to make two way bindings possible :-)

mbrasser

[quote author="njeisecke" date="1305030760"]Hi,

Doing this will generate a console warning:

QML TextInput: Binding loop detected for property "text"

It works nevertheless but I don't like warnings.

Any ideas?
[/quote]

Hi Nils,

Is it the exact snippet above (with a QLineEdit in C++) you are testing or something else?

Typically this warning is avoided via the C++ implementation of the setter, e.g. setText() will be implemented to only emit the NOTIFY signal if the property actually changes. I thought in this case both TextInput and QLineEdit would have done this, though (so there might be something else at play here that I've missed).

Regards,
Michael

andre

Are you suggesting that Qt Quick is at runtime able to analyze if the (C++) objects block emitting a changed signal if you set the same value on a property? And that they only should give the Binding Loop warning if they don't block the signal? That would be pretty cool! But I think that is unlikely. I think it is a warning because it can not be detected if the signal is emitted. If it could, it would (should) be an error instead.

njeisecke

Hi Michael,

my setter was on the c++ side and indeed wrongly implemented (stupid me).

With an implementation like this everything works as expected:

@
void MyObject::setValue(const QString &value)
{
// this avoids the (absolutely correct) warning
if (m_value == value)
return;

m_value = value;
emit valueChanged():
}
@

So actually there seems to be some runtime analysis. Cool ;-)

andre

Does implementing it like this fix the warning? That would be awesome!
If so, then perhaps the warning should be an error instead?

njeisecke

Yes it does, I've just commented out the check and the warning appears.