Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-15928

Binding element when used internally to a component overrides external bindings

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: P2: Important P2: Important
    • 5.0.0
    • 4.7.2
    • None
    • Tested in Linux, latest 4.7 branch

      COMMIT: 6af078b2a13f4855a35d48376e58154ee2d57ec1
    • f609c2f3b148f0d31167b9feeabe8f2c4bbd03b8

      I have a Slider in QML that uses two Binding objects inside it. These objects ensure that the Handle follows the "value" property and vice-versa.

      In other words, I want my Slider to be usable both as an INPUT widget (user drags slider, value changes) and as an OUTPUT widget (application sets value, user sees the handle in a new position).

      See attached example.

      To reproduce:
      1) Run example (qmlviewer main.qml)
      2) Drag slider at the top

      === EXPECTED result ===
      a. Bottom slider follows top slider
      b. Values of both sliders change as stated by the debug text at the very bottom

      === ACTUAL result ===
      (a) does not happen. Bottom slider does not follow the new value set to it.

      I understand this is a loop situation, "s2.value" is being affected by two bindings:

      1) Binding object internal to S2
      2) binding expression written in main.qml (value: s1.value)

      However since these bindings converge, I would expect that to work. If it doesn't, is the only solution to properly implement such widget to do that in C++ or use onChanged() imperative event handlers?

        1. main.qml
          0.4 kB
        2. Slider.qml
          0.7 kB
        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            brasser Michael Brasser (closed Nokia identity) (Inactive)
            fleury Eduardo Fleury
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:

                There are no open Gerrit changes