Handling shortcut() in keyPressEvent
I want to implement a WarningCheckBox class, derived from QCheckBox, which pops up a warning message if I click on the unchecked box, asking for confirmation. If the result is `yes', continue, otherwise do nothing.
Searching for Qt demo code which does something similar yielded no results, unfortunately, so I tried by myself, and I'm stuck somehow to find a satisfying solution.
It seems to me that I have to intercept all events which eventually lead to a checkbox toggle: mousePressEvent and keyPressEvent; the latter should take care of both the space key (which toggles the checkbox by default if it has the focus) and a shortcut.
[What I actually want is a hook which gets called right before QCheckBox is doing the normal stuff for toggling its state; doing so would avoid fiddling with the events directly, but apparently this doesn't exist.]
Handling the mouse click and the space key is trivial. However, what I have problems with is the handling of the shortcut. Here my naïve implementation which fails. [The function `havePermission' pops up the warning message box.]
|| (((hasFocus() && event->key() == Qt::Key_Space)
|| event == shortcut())
The compiler returns an error for `event == shortcut()'
error: invalid conversion from 'int' to 'QKeySequence::StandardKey'
/usr/include/QtGui/qevent.h:736:13: error: initializing argument 2 of
'bool operator==(QKeyEvent*, QKeySequence::StandardKey)'
So my question is: How do I do this correctly?
I take back the
trivial' word. Even the mouse stuff doesn't work as expected: Somehow events seem to get lost. For example, I have to click the check button twice (and say twiceyes' in the pop-up warning message) until I see a check. It is very obvious that I try things which I don't understand.
Any help would be greatly appriciated.
Can you make some prototype ui of what your dialog should look (eg. using Qt Designer). You can upload the image to an image hoster of your choice (DevNet doesn't allow image uploads).
Also, could you rephrase the description of what that dialog should actually do? I didn't understand it completely.
Additionally, you may want to look at [[Doc:QErrorMessage]], maybe it is of use for you. But this is just a wild guess :)
Well, it's not a layout problem, it's an event (or signal?) communication problem within Qt which I don't manage correctly:
I want a simple check box. If it is unchecked, and I
click' on it (either with the mouse or the keyboard), a QMessageDialog should pop up, withYes' and
No'. If I sayYes', the dialog should disappear, as usual, and the check mark should be set.
If I say no, the check mark should not be set.
You should re-think your UI design in general - seriously.
A user expects a checkbox to be checkable directly not via a popup dialog. This is the well expected behavior on all platforms that I ever came across.
Don't change that behavior unless you have very, very good reasons - and to be honest I doubt, that you have (as with almost all similar UI behavior changing requests that pop up here in the forums).
I've meanwhile changed the design :-)
However, there was a very good reasoning for having this warning checkbox: It was intended to activate a feature for which you need a legal permission.
Independently, I would like to know how to implement such a feature, regardless of the UI quality so that I can understand the Qt mechanisms better.
And thanks for you help!
Two possible approaches come into mind:
- disable the checkbox if the user is not allowed to check it;use "QWidget::setEnabled(false) ":/doc/qt-4.8/qwidget.html#enabled-prop
- connect to [[Doc:QCheckBox]]'s "stateChanged":/doc/qt-4.8/qcheckbox.html#stateChanged signal and have the slot popup the dialog
Thanks a lot for your patience!
BTW, I've just found a real example of what I originally wanted to do. Under Windows, you can adjust the behaviour of how files are displayed. For example, there is a checkbox to make Windows show hidden files in folders. If you click on that checkbox, a message window pops up, asking for confirmation. Here you can see it with images:
It seems that my original idea is not that a bad GUI behaviour...