Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Determine whether widget value was changed by user or by software?
Forum Update on Monday, May 27th 2025

Determine whether widget value was changed by user or by software?

Scheduled Pinned Locked Moved Solved General and Desktop
8 Posts 6 Posters 2.1k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    Joachim W
    wrote on last edited by
    #1

    Control widgets like QSpinBox, QCheckBox etc emit signals like valueChanged, stateChanged etc. These signals are caused either by direct user action upon the widget, or by external calls of setValue, setChecked etc.

    I'd like to treat these two cases differently. Is there a straightforward way to find out where the signal comes from?

    Or is there a way to implement alternative forms of setValue, setChecked etc that do not emit valueChanged, stateChanged etc?

    JonBJ 1 Reply Last reply
    0
    • C Offline
      C Offline
      Charlie_Hdz
      wrote on last edited by
      #2

      That's interesting,

      The first approach that comes to my mind is to determine if the mouse is in the widget you're using:

      http://doc.qt.io/qt-5/qmouseevent.html#pos

      I'm neither sure if QTest functions such as QTest::mouseClick move the mouse to the widget nor your specific implementation.

      Kind Regards,
      Enrique Hernandez
      gearstech.com.mx
      chernandez@gearstech.com.mx

      1 Reply Last reply
      1
      • J Joachim W

        Control widgets like QSpinBox, QCheckBox etc emit signals like valueChanged, stateChanged etc. These signals are caused either by direct user action upon the widget, or by external calls of setValue, setChecked etc.

        I'd like to treat these two cases differently. Is there a straightforward way to find out where the signal comes from?

        Or is there a way to implement alternative forms of setValue, setChecked etc that do not emit valueChanged, stateChanged etc?

        JonBJ Online
        JonBJ Online
        JonB
        wrote on last edited by
        #3

        @Joachim-W
        I assume the answer is that you cannot do these things.

        1 Reply Last reply
        0
        • mrjjM Offline
          mrjjM Offline
          mrjj
          Lifetime Qt Champion
          wrote on last edited by
          #4

          Hi
          Can I ask why you need this ?
          We sometimes block signals to avoid GUI triggering user function during
          loading data etc.
          Is that what you need it fo r?

          1 Reply Last reply
          0
          • J Offline
            J Offline
            Joachim W
            wrote on last edited by
            #5

            why I need this? - for logging user actions, and not the system's response to them.

            J.HilkJ aha_1980A 2 Replies Last reply
            1
            • J Joachim W

              why I need this? - for logging user actions, and not the system's response to them.

              J.HilkJ Offline
              J.HilkJ Offline
              J.Hilk
              Moderators
              wrote on last edited by
              #6

              @Joachim-W
              IIRC all such Widgets have a valueChanged signal that is emited when ever the value changed(either software or user) and an editingFinished() that only emits when an user interacted with the class- pressing enter or switching focus.

              Besides that the other option is subclassing for example QSpinBox,
              add 2 new signals e.g valueChangeSystem and valueChangedUser

              a function that is connected to the valueChanged signal

              MySpinbox::customChanged(int value){
                   if(this->hasFocus())
                      emit valueChangedUser(value);
                   else
                      emit valueChangeSystem(value);
              }
              

              Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


              Q: What's that?
              A: It's blue light.
              Q: What does it do?
              A: It turns blue.

              1 Reply Last reply
              1
              • J Joachim W

                why I need this? - for logging user actions, and not the system's response to them.

                aha_1980A Offline
                aha_1980A Offline
                aha_1980
                Lifetime Qt Champion
                wrote on last edited by
                #7

                Hi @Joachim-W,

                there are indeed some widgets that handle both cases differently - for example QLineEdit which has textEdited() and textChanged().

                Unfortunately QSpinBox only has valueChanged() so you can't distinguish it here.

                I think you could subclass QSpinBox and change it so setValue() returns another signal to distinguish between user and program changes.

                You would have to do this for all your widgets, however.

                Qt has to stay free or it will die.

                1 Reply Last reply
                2
                • J Offline
                  J Offline
                  Joachim W
                  wrote on last edited by
                  #8

                  Thank you for your excellent suggestions. For the time being, 'hasFocus' solves my problem.

                  1 Reply Last reply
                  1

                  • Login

                  • Login or register to search.
                  • First post
                    Last post
                  0
                  • Categories
                  • Recent
                  • Tags
                  • Popular
                  • Users
                  • Groups
                  • Search
                  • Get Qt Extensions
                  • Unsolved