专门的QValidator和QML UI更改

1 回答

• 5

  我不认为一个答案可以解决您的所有问题，但我仍然认为有关应用程序结构的一些指导可以帮助您前进 .

  AFAIK那里's no central place that discuss application structure. Actually, there'也没有关于QML中UI结构的建议（例如参见this讨论） . 也就是说，我们可以在QML应用程序中找出一些常见的模式和选择，我们将在下面进一步讨论 .

  在到达那里之前，我想强调一个重要方面 . QML离C不远 . QML基本上是 QObject -派生对象的对象树，其生命周期由 QMLEngine 实例控制 . 在这个意义上，一段代码就像

  TextField {
      id: directoryToSave
      placeholderText: qsTr("placeHolder")
      validator: IntValidator { }
  }
  

  它与使用简单命令式C语法编写的 Validator 的 QLineEdit 没有什么不同 . 正如说的那样，除了一生 . 鉴于此，在普通C中实现验证器是错误的：验证器是 TextField 的一部分，并且应该具有与之一致的生命周期 . 在这个具体案例中，registering a new type是最好的方式 . 生成的代码更易于阅读，更易于维护 .

  现在，这个案子很特别 . validator 属性接受派生自 Validator 的对象（参见声明here和一些用法here，here和here） . 因此，我们可以定义一个 QValidator -derived类型，而不是简单地定义 QValidator -derived类型，而是使用它代替 IntValidator （或其他QML验证类型） .

  我们的 DirectoryValidator 头文件如下所示：

  #ifndef DIRECTORYVALIDATOR_H
  #define DIRECTORYVALIDATOR_H
  #include <QValidator>
  #include <QDir>
  
  class DirectoryValidator : public QValidator
  {
      Q_OBJECT
  
  public:
      DirectoryValidator(QObject * parent = 0);
      void fixup(QString & input) const override;
      QLocale locale() const;
      void setLocale(const QLocale & locale);
      State   validate(QString & input, int & pos) const override;
  };    
  #endif
  

  实现文件是这样的：

  #include "directoryvalidator.h"
  
  DirectoryValidator::DirectoryValidator(QObject *parent): QValidator(parent)
  {
      // NOTHING
  }
  
  void DirectoryValidator::fixup(QString & input) const
  {
      // try to fix the string??
      QValidator::fixup(input);
  }
  
  QLocale DirectoryValidator::locale() const
  {
      return QValidator::locale();
  }
  
  void DirectoryValidator::setLocale(const QLocale & locale)
  {
      QValidator::setLocale(locale);
  }
  
  QValidator::State DirectoryValidator::validate(QString & input, int & pos) const
  {
      Q_UNUSED(pos)                   // change cursor position if you like...
      if(QDir(input).exists())
          return Acceptable;
      return Intermediate;
  }
  

  现在您可以在 main 中注册新类型，如下所示：

  int main(int argc, char *argv[])
  {
      QGuiApplication app(argc, argv);
  
      QQmlApplicationEngine engine;
      qmlRegisterType<DirectoryValidator>("DirValidator", 1, 0, "DirValidator");
      engine.load(QUrl(QStringLiteral("qrc:/main.qml")));
      return app.exec();
  }
  

  你的QML代码可以像这样重写：

  import QtQuick 2.4
  import QtQuick.Window 2.2
  import QtQuick.Controls 1.4
  import QtQuick.Layouts 1.1
  import DirValidator 1.0       // import the new type
  
  Window {
      id: main
      visible: true
      width: 600
      height: 600
  
      DirValidator {             // use it
          id: dirVal
      }
  
      Column {
          anchors.fill: parent
  
          TextField {
              id: first
              validator: dirVal
              textColor: acceptableInput ? "black" : "red"
          }
  
          TextField {
              validator: dirVal
              textColor: acceptableInput ? "black" : "red"
          }
  
          TextField {
              validator: DirValidator { }      // use it
              textColor: acceptableInput ? "black" : "red"
          }
      }
  }
  

  如您所见，使用变得更加直接 . C代码更干净，但QML代码更清晰 . 您不需要自己传递数据 . 这里我们使用的 acceptableInput 与 TextField 完全相同，因为它是由与之关联的 Validator 设置的 .

  通过注册另一种不是从 Validator 派生的类型可以获得相同的效果 - 失去与 acceptableInput 的关联 . 看下面的代码：

  import QtQuick 2.4
  import QtQuick.Window 2.2
  import QtQuick.Controls 1.4
  import ValidationType 1.0
  
  Window {
      id: main
      visible: true
      width: 600
      height: 600
  
      ValidationType {
          id: validator
          textToCheck: first.text
      }
  
      TextField {
          id: first
          validator: dirVal
          textColor: validator.valid ? "black" : "red"  // "valid" used in place of "acceptableInput"
      }
  }
  

  这里 ValidationType 可以用两个 Q_PROPERTY 元素定义：

  • a QString 暴露于QML为 textToCheck

  • bool 属性公开为 valid 到QML

  绑定到 first.text 时，属性设置并在 TextField 文本更改时重置 . 在更改时，您可以检查文本，例如使用相同的代码，并更新 valid 属性 . 有关 Q_PROPERTY 更新的详细信息，请参阅this answer或上面的注册链接 . 作为练习，我将这种方法的实施留给你 .

  最后，当谈到类似服务/全局对象/类型时，使用非instanciable / singleton类型可能是正确的方法 . 在这种情况下，我会让documentation跟我说话：

  QObject单例类型可以以类似于任何其他QObject或实例化类型的方式进行交互，除了只存在一个（引擎构造和拥有的）实例，并且它必须由类型名称而不是id引用 . 可以绑定QObject单例类型的Q_PROPERTY，并且可以在信号处理程序表达式中使用QObject模块API的Q_INVOKABLE函数 . 这使得单例类型成为实现样式或主题的理想方式，也可以使用它们代替“.pragma library”脚本导入来存储全局状态或提供全局功能 .

  qmlRegisterSingletonType是喜欢的功能 . 这也是"Quick Forecast"应用程序中使用的方法，即Digia展示应用程序 . 请参阅main和相关的ApplicationInfo类型 .

  另外context properties特别有用 . 由于它们被添加到根上下文（请参阅链接），因此它们可用于所有QML文件，也可用作全局对象 . 访问DB的类，访问Web服务的类或类似的类都有资格作为上下文属性添加 . 另一个有用的案例与模型有关：C模型，如 AbstractListModel ，可以注册为上下文属性，并用作视图的模型，例如： a ListView . 请参阅可用的示例here .

  Connections类型可用于连接上下文属性和寄存器类型（显然也是单例）发出的信号 . 而信号， Q_INVOKABLE 函数和 SLOT 可以直接从QML调用，以触发其他C槽，如部分讨论here .

  总结一下，使用 objectName 并从C访问QML是可行且可行的，但通常不鼓励（参见警告here） . 此外，在必要和可能的情况下，QML / C集成通过专用属性受到青睐，例如参见QML Camera 类型的mediaObject属性 . 使用（单例）注册类型，上下文属性并通过 Connections 类型将它们连接到QML， Q_INVOKABLE ， SLOT 和 SIGNAL 应该能够启用大多数用例 .

  回复于 2024-05-15T08:20:43+08:00