QML and Qt Quick

I've been trying to solve this by adding a mouse area on top of each list view and although that fixes the scroll issue this isn't exactly a solution: By adding the mouse area, all mouse events are handled by it, so a pressed, released, clicked,.. are no longer handeld by the listview delegate (as they are in the real application, e.g. change the delegate appearance on mouse down). Of course I can propagate the events, but than the scroll issue is back (which makes sense of course). I could also track all mouse events in the mouse area's and manually propagate them to the underlying components but it 'll be a hard job getting everything working. So unless anybody has a solution (please). I'm stuck with te scrollview, not stealing an upward swipe from the listview. Any help would be appreciated

Hi bootchk, thanks for your reply! I tested with Qt.5.4beta and the crash still occurs. I don't think that they have the issue fixed yet.

"https://qt.gitorious.org/qt/qtquickcontrols/source/1ac885f99c15c2bf9859df483048bfa6b68b15f3:src/controls/TextField.qml":https://qt.gitorious.org/qt/qtquickcontrols/source/1ac885f99c15c2bf9859df483048bfa6b68b15f3:src/controls/TextField.qml

I create an issue : https://bugreports.qt-project.org/browse/QTBUG-42203

Thanks ,sierdzio. ; )

The problem can be solved by resetting the state before executing the drop. It's a quirk but works. @ onReleased: { dragTile.state = "" dragTile.Drag.drop() }@

Hi p3c0, thanks for your answers. Your proposed solutions work. And yes the main-problem is the interference of the ParentChange and the drag-handling. BTW: I found a different solution: In the onReleased-handler I reset the state first. This let me keep the ParentChange-handling. @ onReleased: { dragTile.state = "" dragTile.Drag.drop() }@

on QML the objects are not destroyed immediately, but there is something similar to a garbage collector as a concept. So, when you change from screen1 to screen2 the object is not destroyed at the same time, but it's delete later (means that an event of deleting is emitted and when the app process the events will eventually destroy screen1 if no other object are using it). So, in both case the screen1 will be destroyed, but this happen in a different order and that results in something strange from your point of view. If you want to check, put a Timer that every 500 ms print out the child of your Loader object and you can see that the screen1 will be destroyed in any case.

Thanks for replies. No, QGeoSatelliteInfo is not registered because i wanted just to get size of the list. I have read in docs that List<T> where T is non-basic type cant be used for transfer sequences to QML and QList isn't QObject derived class. QQmlListProperty<> should be used for that purpose. So anyway making an new 'proxy' class at C++ side is needed.

Ok. This works now. As long as the drag is active I have to reparent the dragged rect to something global (I introduced a global background rect for that purpose). Thanks for the help.

Hmmm, I must be confused about which version of Qt I was running. I currently have four of them installed for testing purposes. I just re-ran again in 5.3.2 and you are correct it is fixed. FYI, I don't typically save first and I do use the big green Run button on the mode selector panel. (I assume the little green one doesn't do a build just a run). I also used to see the same problem with the Build (hammer) icon. Saving first didn't help. It works fine now, thank you for responding and pointing that out. I'll see if I can kill or update the bug report. Just to make sure I'm not losing my mind I went back to 5.2.1 and the problem was there and is repeatable.

Nevermind, it does work! Sorry about that, I was setting the MouseArea to the wrong place.

Hi Steveg I am using singleton but facing problem if i use more than 2 singleton in one qmldir . can u comment on this.?

Thanks for your reply! Setting contentWidth fixed effectively my problem. Nevertheless, I thought naively that a ListView would adapt its contentWidth/contentHeight accordingly with the space taken by its children.

According to the QQuickItem code "here":http://code.woboq.org/qt5/qtdeclarative/src/quick/items/qquickitem.cpp.html#_ZN17QQuickItemPrivate24setEffectiveVisibleRecurEb the signal visibleChanged() is emitted after the the item is made invisible; if I understood it correctly ;)

No, is at least it didn't when i wrote this. I haven't tried on 5.3, though.