"Canceling" the checking of a checkbox in the slot after a stateChanged() signal has been emitted.
-
Hello,
This is probably a simple request but I want a QCheckBox's "checked" state to remain checked after someone clicks on the QCheckBox in question based on a certain condition.
Here is my slot function which fires but even though I try and change the state back to the original checked state the QCheckBox in question still becomes unchecked.
How do I set up thew slot function so that, based on a condition, the QCheckBox retains the original state even though someone clicks on the QCheckBox?
Thank you.
@
//Connection of SIGNAL to SLOT for Checkbox in question:
connect(chkUseSecuredLicenseServerURL, SIGNAL(stateChanged(int)), this, SLOT(SwitchSecureURL(int)));
//SLOT::
void QTLicenseVerificationOptionsWidget::SwitchSecureURL(int newCheckBoxState) {
if (newCheckBoxState) {
LicensingWidget->setUsingSecureURL(true);
QMessageBox::StandardButton informativeMessage;
informativeMessage = QMessageBox::information(this, tr("Using a secure connection!"), tr("The application will connect to the licensing server securely!"), QMessageBox::Ok);
}
else {QMessageBox::StandardButton warningMessage;
warningMessage = QMessageBox::warning(this, tr("Are you sure?"), tr("You are deciding to use an unsecure URL to connect to the licensing server.\n\nAre you sure you want to do this?"), QMessageBox::Yes | QMessageBox::No);
if (warningMessage = QMessageBox::Yes) {
LicensingWidget->setUsingSecureURL(false);
}
else {chkUseSecuredLicenseServerURL->setChecked(true);
}
}
}
@
-
Hi,
Wouldn't it be more simple to disable the widget while the user shouldn't click on it ?
-
In this case, what I am looking for is this:
The QCheckBox in this case, when unchecked, would allow potentially dangerous behavior.
If the user "unchecks" the QCheckBox, I want a warning message asking the user if they are sure they want to do this.
If they say yes, the QCheckBox is unchecked, allowing said dangerous behavior. If they say no, I want the QCheckBox to remain checked to keep the safe behavior going.
Does that make sense?
Thank you!
-
Ok, then I'd rather use toggled as signal since you don't use a tristate checkbox. You are creating a loop in your slot since you check it again. You should at least block signals when doing that to avoid creating that loop
-
Indeed: use a two-state checkbox and just show your dialog if the checkbox was toggled to unchecked.
I'd also consider using a Qt::QueuedConnection between the toggle signal and the slot handling the confirmation. That will prevent a possible recursion in QCheckBox. The checkbox emits its signals as part of a handling the click on it. That means that at the moment you get the signal, and show your dialog, that code is triggered from within code inside QCheckBox that handles the state change. Now your handling code again changes the state, which means that you end up again inside the code section that triggered your confirmation code in the first place: a recursion. No idea if that is problematic in this case or not, but I'd not risk it and use a QueuedConnection. That way, you can be sure that QCheckBox is done completely handling one state change before getting into the next one.
