Quantcast
Channel: Qt DevNet forums: Qt Quick 1283365070**
Viewing all articles
Browse latest Browse all 4972

The Mystery and Voodoo of Attached Properties

$
0
0
Hi Everyone, I’m trying to work out whether Attached Properties is something I should be using in my current project. This could be a longish post, so please bare with me =) I’ll start off by explaining my goal. And then the source of my confusion =p The goal: I have a root level object, which has a shape container. The shape container… well, contains shapes. Each shape has several “Handles”. The root object has a property which keeps track of a single Handle. Super simplified code/architecture: main.qml Editor {     id: editor     currentHandle: null       ShapeContainer{         shapes: [ /* Insert list of shapes here */ ]     } } MyShape.qml Shape {     Handle{}     Handle{} } Handle.qml HandleCpp {     id: handle     MouseArea {         // Insert MouseArea house-keeping here           /****** THIS IS THE IMPORTANT PART ******/         onEntered: editor.currentHandle = handle         onExited: editor.currentHandle = null     } } Okay, so I think that attached properties are probably a useful thing to have here. And change Handle.qml to do the following instead: onEntered: Editor.currentHandle = handle One of my motivations for doing this is to allow only Handle items to modify this property by implementing it smartly in C++. Which leads me to… The source of my confusion: The docs here [qt-project.org] explain that attached properties DO NOT simply get passed to children items, but have to be attached specifically. And then the example here [qt-project.org] seems to show that the Person class gets the attached property from BirthdayParty implicitly. In conclusion: Is there a way for me to manually select/limit which components have access to an attached property? How can that attached property link back to the attacher (Editor in this case)? (Similar to ListView.currentItem)

Viewing all articles
Browse latest Browse all 4972

Trending Articles