Q_PROPERTY NOTIFY信号及其参数 [英] Q_PROPERTY NOTIFY signal and its argument

问题描述

我习惯用参数编写我的"propertyChanged" signal，这样接收端不需要显式调用Q_PROPERTY的READ函数.

我这样做是出于清楚的考虑，并假设在QML数据绑定的情况下，不需要进行对getter的昂贵"调用来实际获取值，因为该值已作为信号参数传递给QML./p>

我的同事们不同意这一说法，并表示反对"QML风格"，对此我明确表示该文件可能存在一个论点，该论点将采用基础成员的新价值:

MEMBER变量的

NOTIFY信号必须采用零或一个参数，该参数必须与属性具有相同的类型.该参数将采用该属性的新值.

在文档中没有任何地方声明QML绑定系统使用此参数来防止在处理信号时对getter的附加函数调用.我知道此调用可能是用C ++进行的，因此不会进行昂贵的" QML到C ++的调用，但这仍然是一个额外的函数调用，原则上，在进行许多更新时，这可能会导致明显的性能损失./p>

我尝试检查QML绑定源代码，但无法从中推断任何内容.我想知道是否有人知道这笔交易是什么:信号参数是否被使用?

尽管可能，

解决方案

在onPropertyChanged信号中传递已更改的 properties 的值肯定不是 QML样式.

会的，那么您应该至少期望它实现的基本类型很容易显示，而不是.

basictypes.qml

import QtQuick 2.7
import QtQuick.Controls 2.0

ApplicationWindow {
    id: root
    visible: true
    width: 400; height: 450

    property int num: 5
    Button {
        text: num
        onClicked: num += 1
    }
    onNumChanged: console.log(JSON.stringify(arguments), arguments.length)
}

从输出中可以看到，即使更改最基本的一种类型，例如int，也没有传递任何参数.

如果现在QML将使用可选的但很少实现的传递值，则此会产生开销，因为您在使用它之前始终需要检查参数的存在.尽管简单的检查并不会昂贵，但是如果它通常评估为false，然后您使用了解决方法，为什么要事先这样做呢?

尽管我可能不能排除，但在官方领域中的任何onPropertyChanged信号中都没有任何传递的值，但在property [type] [name]中的QML中添加的属性均没有.对于大多数继承的属性，也没有任何属性(已测试Button:text，width，height).

I have the habit of writing my "propertyChanged" signals with an argument, such that the receiving end doesn't need to call the Q_PROPERTY's READ function explicitly.

I do this out of clarity and the assumption that in a QML data binding situation, no "expensive" call to the getter needs to be done to actually fetch the value, as it's already passed to QML as a signal argument.

My colleagues disagreed and said it was against "QML style", to which I responded the documentation clearly states it may have an argument that will take the new value of the underlying member:

NOTIFY signals for MEMBER variables must take zero or one parameter, which must be of the same type as the property. The parameter will take the new value of the property.

Nowhere in the documentation is it stated that the QML binding system uses this parameter to prevent an additional function call to the getter when handling the signal. I understand this call will probably be made from C++, so no "expensive" QML to C++ call will be made, but it still is an extra function call, which in principle could result in a visible performance penalty in case of many updates.

I tried inspecting the QML binding source code, but couldn't infer anything from it. I wonder if someone knows what the deal is: is the signal argument used or not?

解决方案

Passing the values of the changed properties in the onPropertyChanged-signal is, though possible, most surely not the QML style.

Would it be, then you should expect that at least for the basic types it is implemented, which is easily shown, it's not.

basictypes.qml

import QtQuick 2.7
import QtQuick.Controls 2.0

ApplicationWindow {
    id: root
    visible: true
    width: 400; height: 450

    property int num: 5
    Button {
        text: num
        onClicked: num += 1
    }
    onNumChanged: console.log(JSON.stringify(arguments), arguments.length)
}

As you can see in the output, that there are no arguments passed, when you change even one of the most basic types, such as int.

If now QML would use the optional, but rarely implemented passed value this would create overhead, as you would always need to check the existence of the argument before using it. Though a simple check is not to expensive, if it usually evaluates to false, and then you use the workaround, why do it beforehand?

Though I might not rule out, that there are any passed values in any onPropertyChanged-signals in the official realse, there are none for properties added in QML with property [type] [name]. There also none for most inherited properties (tested the Button: text, width, height).

这篇关于Q_PROPERTY NOTIFY信号及其参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！