QML and Qt Quick

@RynoJ Two observations: C# is a lot closer to C++ than to Python, which is a completely different language. QML is a declarative language, and not really a programming language. Quite different from normal procedural programming like C# (or for that matter C++ or Python). It is a totally different paradigm. Depending on what you did in C# about e.g. the UI, using Qt widgets (with either C++ or Python) would likely be a lot closer than anything QML.

A QML singleton file is hardly more complicated and has the benefit of being typed and using a proper module import, making the tooling easy. // Globals.qml pragma singleton import QtQml QtObject { readonly property string defaultUrl: "https://www.qt.io" }

Please try a more recent Qt version. 5.15 is EOL. I can’t reproduce this on 6.5.

That depends on what you specify for your UX. If you don't want to have to use a submit button then mapping each textfield to a c++ property is the more direct way yes. Doing that on editingFinished is a good solution.

@SeeLook, is it accessible from outside QML?

Sounds correct yes.

This import does not import a file, but a directory, which is why the above error is always reported: no such directory I understand a little bit now. The use of qml is like the classes and objects of c++. What are defined in the qml file are types. When using them, they cannot be directly referenced by the type name (unless a singleton object is defined). Instead, an object instance should be created using the type defined in qml, and then this instance object should be referenced. For example: [image: 657e3e2e-02f6-4281-a2e6-b140b5aaa175.png] [image: 2b622949-0b55-46e7-82e9-4037d087037f.png] [image: 9f3149dd-971c-4580-a884-3aaa349f0e46.png]

Use client-side validation in QML (e.g., IntValidator, DoubleValidator) for immediate input checks. After that, call a C++ Q_INVOKABLE method to perform server-side validation (e.g., check for unique name/image in the database). Ensure the database check is asynchronous to avoid blocking the UI, and provide feedback if the check fails (e.g., show an error message if the name/image isn't unique). This ensures both local and database validation while maintaining a smooth user experience.

To address this problem, you can try improving the dynamic sizing logic of the dialog using a more flexible approach that leverages implicit sizes more naturally. Here is an updated version of the dialog component, with improved sizing logic to handle dynamic text wrapping without manually adjusting the size of the dialog: import QtQuick 2.9 import QtQuick.Controls 2.2 Dialog { id: dlg visible: true title: "My Dialog" property var msgText: "" // Initialize msgText to avoid undefined issues property var parentWindow width: Math.min(buttons.implicitWidth * 1.5, parentWindow ? parentWindow.width : 600) height: Math.min(msg.implicitHeight + footer.implicitHeight + 20, parentWindow ? parentWindow.height : 400) x: (parentWindow ? parentWindow.width : 600) / 2 - width / 2 y: (parentWindow ? parentWindow.height : 400) / 2 - height / 2 header: Label { text: dlg.title font.bold: true } Text { id: msg text: msgText || "No message provided." width: dlg.width - 40 // Padding for the dialog's width textFormat: Text.StyledText wrapMode: Text.WordWrap anchors.horizontalCenter: parent.horizontalCenter color: "black" } footer: Item { width: dlg.width height: buttons.implicitHeight Row { id: buttons anchors.horizontalCenter: parent.horizontalCenter padding: 5 spacing: 10 Button { text: "OK" onClicked: dlg.accept() } Button { text: "Cancel" onClicked: dlg.reject() } } } }

It has been resolved. It was caused by selecting a different version of Qt in the build configuration

Thanks guys, this was that.

Easy way - QChar has a constructor that takes unicode. QChar sdegree(0x00B0);

Seems to work with qsTranslate in qml and QT_TRANSLATE_NOOP in the vector (inspired by http://imaginativethinking.ca/how-the-heck-can-i-use-qstr-with-variables/). Thank you all.

The problem is that every unique value of grAnim causes a new texture to be generated and stored in the cache: https://bugreports.qt.io/browse/QTBUG-136553

The existing answers are correct, but to amend them: With qmlRegisterSingletonInstance, the same instance is shared by all engines (which can be somewhat problematic when there's more than one), whereas with qmlRegisterSingletonType, each engine will end up with its own instance. Please see also https://doc.qt.io/qt-6/qml-singleton.html , especially the sections on "Exposing an existing object as a singleton", "Imperative type registration" and "Guidelines for (not) using singletons".