QML and Qt Quick

@fromis_9 said in QML Defines reusable types issue.: Column { anchors.fill: parent HeaderSlider { Layout.fillWidth: true; Layout.fillHeight: true Column is not a layout, so Layout.fillWidth will not work! Use ColumnLayout instead.

I was merely ensuring that I understood your intentions correctly. As @GrecKo wrote, and I would have given the same advice, your detection code should be independent of your UI. Mixing the information you gather with states rather than creating different QML files looks to be a good way to get your application working the way you want.

I know I'm too late, but...I was also interested in this problem and found the following in the qt source code: The difference between a GeoMapObject and a MapItem is twofold. First, GeoMapObject are always backed by a plugin-specific implementation and do not come with a default implementation. If a plugin does not support a specific GeoMapObject type, adding such a GeoMapObject will have no effect. Second, GeoMapObject are not QQuickItems, thus being a much more lightweight way to add content to a map. GeoMapObject support is plugin-dependent, and is documented per plugin.

No more help!? :(

Did I just find the one legitimate use for eval? let buttons = [] for(let ind=0; ind<6; ++ind){ let obj = {button: eval("xmBtn%1".arg(ind+1))} console.log(JSON.stringify(obj)) buttons.push(obj) } statusButtons = buttons

@GrecKo Perfect! Thank you :)

Okay, feeling a little bit better about this. My test case is something that shouldn't happen anyway: import QtQuick 2.15 import QtQuick.Window 2.15 Window { width: 640 height: 480 visible: true title: qsTr("Wheel Handler Issue") Item { anchors.fill: parent WheelHandler { objectName: "handler1" onWheel: { console.log(objectName) event.accepted = true } } } Item { anchors.fill: parent WheelHandler { objectName: "handler2" onWheel: { console.log(objectName) event.accepted = true } } } } Item precedence solves the need to redefine WheelHandler if needed. result: qml: handler2 Handler 1 no longer fires. Yay!

The difference is just a convention now. Both slots and Q_INVOKABLE can be called by invokeMethod and meta-object system. Slots can have a return type. What I usually do is use slots for function that modify the state of the object and invokable for helpers returning or transforming data, usually taking some parameters.

@riodoro said in Unable to assign [Type] to [Type] in QML: hi, you can use only basic types in qml object properties. That's wrong. I'm using custom types since ages. As long as a type inherits from QObject, it can be used as property in QML.

I make my own split view for my purpose. import QtQuick 2 import QtQuick.Layouts Item { id: splitView RowLayout { anchors.fill: parent spacing: 0 Rectangle { Layout.fillWidth: true; Layout.fillHeight: true id: leftItem color: "red" } ToolSeparator { Layout.fillHeight: true id: handle property int leftLimit: 0 property int rightLimit: splitView.width MouseArea { anchors.fill: parent id: handleMouseArea acceptedButtons: Qt.LeftButton cursorShape: Qt.SplitHCursor onMouseXChanged: { /* Mouse position in the SplitView*/ var pos = mapToItem(splitView, mouse.x, mouse.y) if (pressed) { var xPos = pos.x - handle.width / 2 if (handle.leftLimit < xPos && xPos + handle.width < handle.rightLimit) { /* This is basic functionality of SplitView */ handle.x = xPos leftItem.width = handle.x rightItem.x = handle.x + handle.width rightItem.width = splitView.width - leftItem.width - handle.width } } } } } Rectangle { Layout.fillWidth: true; Layout.fillHeight: true id: rightItem color: "blue" } } } any better?

Found solution onFocusChanged: function(focus) { if(focus && focusReason === Qt.TabFocusReason) selectAll() }

Good morning, thank your for your reply. These should not be necessary, and might be the reason for your double-ups. What's the purpose of adding these lines? The double-ups are in fact happening on a new project without these lines. However, adding these will allow me to build the project again so that it compiles on the second try. That is really scary and sounds extremely fragile, so I'm hoping for a solution. The purpose for these lines was to deparate the build output in Qt Creator into a debug and release folder, thinking it would affect the migration to a Visual Studio project in some manner since it looked like the Qt VS Tools project was trying to RCC in both debug and release mode even though I have the Debug x64 configuration selected. There was no way to suppress this behavior and only RCC debug files. As a short follow-up after writing this paragraph, here's a description of this issue: The build might fail in the first place since it searches for *.qm files in the /release output folder when building in debug mode Starting a build and letting it fail in release mode fixes this issue Restarting the build in debug mode will display the following warning C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(514,5): warning MSB8028: The intermediate directory (build\debug\.obj\) contains files shared from another project (Hydra.Frontend.vcxproj). This can lead to incorrect clean and rebuild behavior. After that it will fail with the following errors: 1>\Hydra.Frontend\build\Debug\.qrc\qrc_qmake_qmake_qm_files.cpp : fatal error C1083: Cannot open compiler generated file: '\Hydra.Frontend\build\debug\.obj\qrc_qmake_qmake_qm_files.obj': Permission denied \Hydra.Frontend\build\Debug\.qrc\qrc_qmake_qmake_immediate.cpp : fatal error C1083: Cannot open compiler generated file: '\Hydra.Frontend\build\debug\.obj\qrc_qmake_qmake_immediate.obj': Permission denied Building again fixes this issue if and only if the lines added to the project file were present. The fact that an assertion occurs likely indicates that something has gone wrong, or an assumption has been violated. So I wouldn't simply dismiss it as an annoyance. Does the assertion occur with a very basic "hello world" Qt Quick project? It does in fact not. Though since it happens in the call of creating a window and appears to be thrown on a separate thread and I was so far unable to isolate the issue I feared it would become a time sink. So, how about overcoming fear, I'm gonna investigate this issue further and will follow up with a resolution or perhaps a more detailed description. Update 1) The issue is related to my QML Code/Native registered components Update 2) Found the root cause for the assertion. I have a QML component that defines the following two properties: property bool isToggle: false property bool toggled: false If any of the two properties is named differently then the assertation is not triggered. This seems extremely weird to me and looks to me like unwanted behavior

@Soheil Do you happen to know if this blob-encoding is an officially supported way to display images? For large images, the extra work of encoding the byte array into a QUrl seems excessive. For small SVGs, this might be a good solution for me.

Thanks for the replies, guys. I'm pretty new to QML, so the binding example is very helpful. I still think these text controls desperately need improvement, though.

It's because the material style sets non-zero values for xxxInset properties. Set leftInset, rightInset, topInset, bottomInset values to 0 and the button appears to fill its parent.