Unsolved Add PropertyChanges to a State in a derived QML component
-
Hi all,
I have a QML component "comp1" which defines a state "state1" and a 2nd component comp2 which derives from comp1. Now I want to add (!) a PropertyChanges definition in comp2 to the state derived from comp1 without overriding the definitions in comp1. How can I achieve that?
comp1.qml:
Item { id: item property color color1: "white" states: [ State: { name: "state1" PropertyChanges { target: item; color1: "green" } } ] }
comp2.qml:
Comp1 { id: item property color color2: "black" states: [ State: { name: "state1" PropertyChanges { target: item; color2: "red" } } ] }
main.qml:
... Comp2 { state: "state1" } ...
-
@DuBu 'states' is a (javascript) array of objects, maybe you can manipulate State objects dynamically in Component.onCompleted. Loop through the array and find the object where the property 'name' is "state1". Then take the first object in the 'changes' array and manipulate it.
-
@Eeli-K I'll give it a try, but it forces me to leave the declarative way.
-
The derived component can have a private object with a state binded to outter scoped state with its own set of property changes:
Comp1 { id: item property color color2: "black" QtObject { id: internal state: item.state states: [ State: { name: "state1" PropertyChanges { target: item; color2: "red" } } ] } }
-
Sorry to bump an old thread, but this is still unsolved and very needed.
First thing to mention,
list<>
types are NOT javascript arrays, and can not be manipulated from QML. Which is kinda stupid and inconvenient.Second, states can extend each other via
extend
property. But it does not work well with awhen
condition: in my case with identical conditions state switches (from default) to subcomponent's overridden extended state, and then immediately to base component's state; so any property changes to subcomponent are undone even before we have a chance to see them.As much as I'd like to hear from Qt experts opinion on this matter, it seems list manipulation and subclassing topics are just silently omitted in docs. The only proper solution, in spirit of QML, would be to support such extensions at the language level via special syntax.