QML and Qt Quick

Don't create logical loops. Window { id: root width: 640 height: 480 visible: true property int myValue: 0 Slider { id: slider x: 350 y: 212 stepSize: 1 to: 10 value: myValue onValueChanged: myValue = value; } Switch { id: switch1 x: 175 y: 209 text: qsTr("Switch") checked: myValue >= 5 onClicked: { if(checked){ myValue += 5 }else{ myValue -= 5 } } } } Honestly though, you should have an indicator and 2 separate buttons to increment and decrement. Not sure what you are trying to do here.

I tried my idea above, and it seems to work (this code called from a main.qml): Item { anchors.centerIn: parent CircularSlider { id: circularSlider anchors.fill: parent ... } CLabel { id: nbr anchors { right: parent.horizontalCenter rightMargin: 3 baseline: parent.verticalCenter } text: Number(circularSlider.value).toFixed() font.pixelSize: 24 font.weight: Font.Bold } CLabel { anchors { left: parent.horizontalCenter leftMargin: 3 baseline: nbr.baseline } text: "gpm" } } Produces this: [image: 76bfd35b-2f11-4de9-ba9c-071c948ba6dc.PNG] Thanks for looking...

use QQuickWidget https://doc.qt.io/qt-6/qquickwidget.html#details thats what that is for. However, you may need to change your root component from a Window to a Rectangle or something similar

I found out that the horizontal Scrollbar was the problem, setting: ScrollBar.horizontal.policy: ScrollBar.AlwaysOff Fixed it.

@Bob64 said in Where to find?: @sierdzio apologies for the slight diversion, but what would be the modern (5.15/6) approach to this sort of import? I need to start learning about this stuff as I am going to be in the position of bringing a 5.9 project up to date soon - initially to 5.15 but ultimately to 6.x in the not too distant future. I'm not an expert on that, still stuck on Qt 5.12 on my main project now :/ But the new approach is more centered about new macros that automate this registration: https://doc.qt.io/qt-6/qtqml-cppintegration-definetypes.html#registering-an-instantiable-object-type See: QML_ELEMENT, QML_IMPORT_NAME etc.

@jsulm Thank you so much for supporting! I tried with Hercules or Terminal v.1.9 software. XCTU software only respones when receive hex and return text or hex. But probably my problem because of XCTU received/ sent type data

This is right approach. You can refer

@drmhkelley said in re-compiling (cached) qml components: Ooops - stopped paying attention for a bit, but thanks very much for the additional imformation. No problem. For your new questions: Version of Qt 5 was Qt 5.15. The app was developed starting with version Qt 4.??, but I kept it going through 5.15. Great! files managed inside a *.qrc file ... What specifically do you mean by "run your compilation"? Are you referring to the steps I specifically initiate via "make"? I meant "run qmake + make" Or do you refer to steps taken more indirectly through the QML compilation engine? That's where I start getting pretty confused. Programmers are not meant to run the QML compiler directly. Most of the time, you don't even have to think about it because qmake and make take care it it for you automatically. Also, what uses the info in the .qrc file? It is referenced in the .pro file (RESOURCES += ...), but it isn't obvious what is done with that. I don't use either qmake or CMake - never found a "simple" enough explanation/example to figure them out. Instead, I just use mingw32-make, which I've used extensively for many eons. At the core of it, qmake converts your *.pro file into a Makefile. Programmers would run qmake first, then run make. when qmake sees the RESOURCES += ... in your *.pro file, it writes the relevant rules into your Makefile to run rcc.exe. Anyway, this might be the source of your problem. rcc.exe reads the *.qrc file, collects the latest version of the resource files, and embeds them into your executable. If you have a *.qml file that isn't listed in the *.qrc file, or if your Makefile does not contain rules to invoke rcc.exe when those files are changed, then that would explain why your modified *.qml files are not getting processed. If you're running mingw32-make directly but not running qmake, that means your *.pro file is not actually getting used at all. You can probably delete the *.pro file and see no difference. "multiple versions of Qt" with single Qt Creator. When I was first starting to use Qt, I tried to do that, but was never successful. Can you point me to any simple description of how to accomplish that? Use the Qt Online Installer to install all the versions of Qt that you want (ensure that you have also installed the relevant compilers too) Create or open a project in Qt Creator. It will ask you which installed version(s) of Qt you want to use with your project, so make your selection. Click the "Run" button to build and run your application with your first selected version of Qt. Use the "Kit Selector" to select a different version of Qt, and click the "Run" button to build and run your application with that other version of Qt (see https://doc.qt.io/qtcreator/creator-building-targets.html for the diagram) That's the gist of it. Many thanks for the pointers to ports of positioning and location to Qt 6. When I first converted to Qt 6, I tried to keep up with that, but stopped once it seemed unlikely to ever reach any sensible stage of utility. I will definitely look more into whether the current status allows users like me to use them productively. Many thanks 👍

yes and I already use it, but it's a shell designed for a mouse and optimized for a touchscreen, what I'm trying to achieve is a dock specifically designed for a touchscreen I'm sorry if this is the wrong community to ask, I'll try asking somewhere else!

@JKSH using Dependencies, I found this: [image: 8ba0ed0b-a1c4-4229-a9f1-814f3946585d.PNG] It turns out that in Qt 6, the Shader tools are a separate component that must be explicitly checked during installation. I guess I'm still getting used to the more "modular" approach to Qt 6. Thanks for the help.

Hello again! I digged a little deeper into this behavior and found out, that the SwipeView actually has a clue on what's going on with its currentItem, but do not tell the world about that. Therefore I've added some more loggings and stuff to the Repeater: [...] Repeater { id: errorRepeater model: control.errorModel onItemAdded: { console.log("item added: " + item) console.log("errorview currentItem: " + errorview.currentItem) } onItemRemoved: { console.log("item removed: " + item) console.log("errorview currentItem: " + errorview.currentItem) } onCountChanged: { console.log("count changed") console.log("errorview currentItem: " + errorview.currentItem) updateItems() } signal updateItems delegate: Item { id: theItem Connections { target: errorRepeater onUpdateItems: { console.log("updateItems catched") visible = errorview.currentItem === theItem } [...] } } } With that you can see the following when an item gets removed from the Repeater: 2022-10-10_16:31:59.696 I m_ErrorModel: found item to delete: 0 (rows before: 4) 2022-10-10_16:31:59.696 D onRowsAboutToBeRemoved 2022-10-10_16:31:59.696 D onRowsRemoved 2022-10-10_16:31:59.696 D QQuickItem_QML_76(0x30211c0): repeaterIndex changed to: -1 2022-10-10_16:31:59.696 D QQuickItem_QML_76(0x3051c10): repeaterIndex changed to: 0 2022-10-10_16:31:59.696 D QQuickItem_QML_76(0x2a2e0a0): repeaterIndex changed to: 1 2022-10-10_16:31:59.696 D QQuickItem_QML_76(0x3248430): repeaterIndex changed to: 2 2022-10-10_16:31:59.696 D item removed: QQuickItem_QML_76(0x30211c0) 2022-10-10_16:31:59.696 D errorview currentItem: QQuickItem_QML_76(0x30211c0) 2022-10-10_16:31:59.696 D QQuickItem_QML_76(0x3051c10): swipeIndex changed to: 0 2022-10-10_16:31:59.697 D QQuickItem_QML_76(0x2a2e0a0): swipeIndex changed to: 1 2022-10-10_16:31:59.697 D QQuickItem_QML_76(0x3248430): swipeIndex changed to: 2 2022-10-10_16:31:59.697 D count changed 2022-10-10_16:31:59.697 D errorview currentItem: QQuickItem_QML_76(0x3051c10) 2022-10-10_16:31:59.697 D updateItems catched 2022-10-10_16:31:59.697 D updateItems catched 2022-10-10_16:31:59.697 D updateItems catched 2022-10-10_16:31:59.697 D QQuickItem_QML_76(0x3051c10): visible changed to: true (w: 640 | h: 200) 2022-10-10_16:31:59.697 I errorModelChanged catched As you can see, does the errorview's currentItem change after the SwipeIndex' of the items have been updated and the count of the Repeater items changes. The logged currentItem then is the one that I actually want to be visible and it is the one with SwipeView.index of 0. I then going to send a signal to update the visibility of the actual currentItem... BUT... the result is still the same :( Sometimes the item is visible, sometimes it is not. It's a mess. Regards, matzze

"One solution would be to add the toggleableItem.y in front of the binding expression so that the binding is always reevaluated if the y property changes. Basically, make the binding dependent on a geometric property that changes when the item is re-positioned." readonly property point absolutePosition: { toggleableItem.y // geometric property in binding to trigger re-evaluation return toggleableItem.mapToItem(toggleableItem.rootItem, 0, 0) } SOURCE for answer and also credit to @fcarney

Ok I test other solution, thanks you

Thanks, but I just solved it by using: if(!inputField.activeFocus) inputField.cursorPosition = 0; at the onTextChanged event

@J-Hilk that was it (sometimes the most obvious omissions are the hardest to find). clock.cpp: Clock::Clock(QObject *parent) : QObject{parent} { connect(&m_timer, &QTimer::timeout, this, &Clock::update); m_timeStr = "00:00 AM"; } void Clock::setTime(const QString &time) { if (time != m_timeStr) { m_timeStr = time; emit timeChanged(m_timeStr); } } void Clock::update() { QString l_timeStr; m_time = QTime::currentTime(); l_timeStr = m_time.toString("hh:mm AP"); setTime(l_timeStr); } I had to move the m_timer.start() out of the c'tor, because I got this runtime error: QObject::startTimer: Timers can only be used with threads started with QThread So I created a start() function and I call it from main.cpp. Works like a charm now. Thanks!