QML and Qt Quick

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() } } } }

@Jyothi Thanks for the response. I have no problem with using translations in QT, I do it for multiple languages. The problem is that one translation is used in multiple places, and thus I want to incorporate preferred line break in the translation itself. The other option is to duplicate the translation string and use one on each place, but that quickly turns cumbersome when you have thousands of strings. I try to minimize the amount of duplicated strings in the application.

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".

Improperly explained problems lead to bad answers. I'm not sure I properly understand what you are asking so I probably won't answer it either and each time I read your question I understand a completely different thing of the previous read. I've read five times and I'm still unsure about what I should understand. If I'm understanding it right, you might be willing to instanciate an object outside a Loader, but be able to access it within it ? if yes then you need to use a binding. Item { id: rootItem SerialData { id: serialData } Loader { id: loader source: someCondition ? "page1.qml" : "page2.qml" } Binding { target: loader property: "serialData" // the property name as it will be available inside the loader WITHIN PARENTHESES value: data } } and inside your loader you can access your property classically via rootItem.serialData other option : you want to instantiate your SerialData component inside some component and make it accessible to it's parent. Then you can declare it as a property inside the component that instanciates it and thus make it available to the parent component. Doing this for data properties is fine, but injecting out an object is bad architecture. That's a very bad choice. It is much cleaner to create it in the main page and inject it into the subpages rather than creating it in a subpage and injecting it out to the main page and back to the siblings.

@JoeCFD Hi, Do you know of any sample code?

You're right, thanks. Running with paramter "-platform xcb" works. (Then, of course, it is no longer Wayland)

Hi all, The issue is now resolved. The project I was porting required glibc 2.29, whereas RHEL 8.10 only supports up to glibc 2.28. When I installed Qt using the online installer, it was expecting 2.29, rather than the system provided version. I couldn't find any precompiled Qt libraries for my version of RHEL, so I rebuilt Qt from source using the system provided version of glibc, and now there is no crash. Thanks for the responses!