EnabledChanged () [signal]
-
It would be convenient if we had a signal, void QAbstractButton::enabledChanged () [signal] to that buttons emit this signal with the enabled state changes. I am surprised it is not there yet! I see QGraphicsObject gets it, but not buttons. I dont have access to the bug or feature list request -- can someone post this if it is felt to be a good idea? If folks think it a bad idea, please tell me why...
-
You can track a status of a property "enabled" using "changeEvent()":http://qt-project.org/doc/qt-5/qwidget.html#enabled-prop
There was a similar suggestion about "QAction":https://bugreports.qt-project.org/browse/QTBUG-3565 and it was closed.
-
I saw that, but to use the changeEvent, wouldnt I have to subclass the QPushButton or whatever class to use that? Or write a changeEvent method in a dialog, but then a big loop to figure out who sent the changeEvent to act on it appropriately. If I had a signal emitted, I could just connect objects together using connect() without doing a subclass or write a big changeEvent method. Should be much easier to link objects together whose enabled status need to be linked.
-
Hi,
You can also use a an event filter on your button, or create a subclass of QPushButton with that additional signal and use it in your code.
-
thanks again, but I was looking for an even easier solution -- the signal/slot mechanism works pretty well, so if I could just connect two widgets using enabledChanged on one to propagate to the other without making a subclass, to me that is easier, the code would also be simpler than an event filter.
-
Yeah, I don't think it is possible without creating your own widget.
But you don't need to implement the whole widget logic.
In new class declare enabledChanged() signal and rewrite setEnabled() member to emit that signal after calling setEnabled() from base class. Rest of the logic will be done by the base class. -
Out of curiosity, can you tell us your use case for that feature ? Since generally disabling a widget based on some condition is more of a relation between e.g. a button checked state than a button disabled state
-
I was putting together a dialog with a lot of buttons, and several buttons become interdependent. I have not used checkable and checked() on QPushButtons, I dont think that is the behavior I want. I want to be able to make certain buttons inaccessible depending on certain events, not to push/unpush them. So far, the enabed(true/false) works well, setting enabled(false) grays out the button face and makes it unresponsive. If I change the checked state to true, the button looks like it is pressed, which would be confusing to the users. So when certain events happen, I do a check on all the buttons, with code that looks something like:
@
button1.setEnabled(<some condition>);
button2.setEnabled(button1.isEnabled())
.
.
.
etc
@I still think it would be easier to connect button1 to button 2 with an enabledChanged event rather than this type of code, which is prone to errors.
Question to you: why is enabledChanged useful in a QGraphicsObject, but not in a button?
-
[quote author="nekkceb" date="1397058014"]I want to be able to make certain buttons inaccessible depending on certain events, not to push/unpush them.[/quote]
This sounds like a good case for "State Machine":http://qt-project.org/doc/qt-5/statemachine-api.html
-
andreyc has a good point with the State Machine suggestion
To answer your last question: essentially different use cases
