[Solved] Preventing a QRadioButton from toggling
-
I have a QRadioButton on a form, and I've connected its clicked() signal (by way of right-clicking and choosing Go to Slot) to a slot function in the .cpp file. I want to get the clicked() signal and execute the slot function, but I don't want the button to be toggled. As far as I can tell, the blockSignals() method will prevent the clicked() signal, and I don't want that. How can I prevent the button from toggling while still executing the slot function?
-
Certainly you could set in the slot method the radio button to the state you like. However, this may involve some short flickering of teh radio button to the undesired state.
I have not tried yet, but I am wondering if you could set your own icon with "setIcon":https://qt-project.org/doc/qt-4.8/qabstractbutton.html#icon-prop
QIcon allows you to add different files for different states with "addFile":https://qt-project.org/doc/qt-4.8/qicon.html#addFile . -
This is what I'm currently setting the stylesheet to:
@
"QRadioButton::indicator { height: 25px; width: 27px; }"
"QRadioButton::indicator::unchecked { "
"image: url(:/PushButtonPix/Unforced_Zero.png); }"
"QRadioButton::indicator::checked { "
"image: url(:/PushButtonPix/Unforced_One.png); }"
@
I guess I could set both the checked and unchecked states to the same image, but this will cause some other coding problems elsewhere. I'd like to avoid this route. -
My main question is: why?
A radio button that does not check if you click it, even if it appears enabled, is highly confusing for your users. That is not how radio buttons are expected to work, so it is not supported (though some hacking would probably make it work).
-
I'm building an HMI for a machine tool. My program is a slave to the PLC program running the tool itself. When the radio button is clicked, I'll send a request to the PLC to clear or set an output, but I need confirmation back from the PLC because I don't have actual control of the output. Under normal operation, I'll get a response back from the PLC relatively quickly, and I can set the state of the radio button. I don't want to "assume" the state of the output before the PLC sets it.
-
Thank you for explaining what you are trying to do. It makes sense. I think it is an interesting problem from a UX point of view first, and a programming point of view second.
First, the question may be: what kind of feedback do you want to provide the user at what stage of the process? The process would look like this, right?
User: request change by clicking radio button
System: register request, request change in backend (PLC)
PLC: register request
Succeed
Fail
System:
Register changed state
Note that the state did not change
Update UI to reflect any changes
So... How do you keep the user informed that step 2 worked, while the backend my lag and/or fail? How do you inform the user the change failed?
Personally, I think that just not setting the radio checked value yet is not going to cut it. It will make your user think step 2 failed, resulting in frustration and just hitting it again. I think feedback is critical, but QRadioButton does not provide that out of the box.
Which brings us to the second question: what would be needed on the programming front to make a setup like yours work nicely? Perhaps a set of widgets would be needed where the action and the state are decoupled, and intermediary states are supported to indicate the transition. Very interesting issue all in all.
Thanks for bringing this up!
-
A three state radio button would be a solution. BTW I am not sure if one should still call it radio button then. You may want to consider it like a button changing its state like a traffic light.
First state is red.
button pressed it will become yellow.after acknowledge of application it will be come green.
if not acknowledged after some time, set back to red.I am using the traffic light as an example, but the same could be realized through different shades of grey or different shapes.
-
Because I found the question intreaging, I took the liberty of "posting":http://ux.stackexchange.com/q/19312/13223 it on the User Experience stack exchange. I think the suggestion there is very interesting, but it will be quite hard to implement using Qt Widgets. Still, the idea is very neat.
!http://i.stack.imgur.com/qIP3k.png(Suggested solution from UX StackExchange)!