QML and Qt Quick

@sierdzio thanks for answer, my problem solved thank you

Is it any solution for this?

Still the problem with a property of FileDialog to bring the explorer window to select the file exits: Cannot assign to non-existent property "folder". I also tried currentfolder but the same error message!

@KH-219Design yes, it's a segmentation fault. Would you please tell me how to capture the backtrace/callstack? When debugging I can see only a lot of disassembled code, but no one function (in any thread) is my code. I can prepare a sample project for you. In the meanwhile, can we generalize a bit the question? How to skip a step in a SequentialAnimation if some conditions are met?

Looks like you're using an OpacityMask on your Button but without radius being taken into account. Otherwise, post the snippet of code that produces the effect you show in your image, it might be easier to assess what's happening.

@juvf said in QtQuick.VirtualKeyboard, slow language change: Why? The startup passed a long time ago. I guess layouts are loaded via a Loader element. So when it's sourceComponent is changed (to another layout), the data is loaded fresh. So this implies you could create a custom layout, make it small and fast and it will load fast. Or make it lazy-load and it will also look faster than it is (here I mean: initially load just empty rectangle, then fill in all the keys). A lot of the details are described here: https://doc.qt.io/qt-6/technical-guide.html

My approach was lossy. QDate loses time information. Changing data type for C++ to QDateTime keeps the time info even if I don't need that. The time zones have an affect. It seems JS Date can interchange between C++ QDate or QDateTime. QDateTime is the preferred and doesn't cause errors.

I've decided to move all properties to c++ and not use properties within QML itself. As such, this issue isn't relevant anymore, but I'd still be interested to understand what's going on here. I suspect it's due to the Drawer's parent being the Overlay, rather than the mainItem itself.

Problem not solved, but identified. The contentHeight of the flickable region is set to the height returned by the bounding rect of the text. Seems FontMetrics.boundingRect does not take into account newline characters, so the returned width is over 15,000 pixels wide but the height is 20, the height of a single line at the designated font point size. Though even this obvious bug in QML does not explain why even trying to scroll right would snap back to the origin when the mouse was release.

@qcoderpro said in Fusion Style: I should add that line in the CMakeLists.txt file of the project. Right? yes

@Praveen-Illa I am so sorry. I posted the wrong link yesterday. doh! https://doc.qt.io/qt-5/qtquick-modelviewsdata-modelview.html This is what I meant to post. lol

I found it very helpful

Hi, Might be a silly idea (and I currently don't know the performance hit for that one) but why not have one mouse area per Text object ?