[PATCH] make KMessageBox::warningContinueCancel do what it says
Martijn Klingens
mklingens at yahoo.com
Sun Apr 7 13:46:27 BST 2002
On Sunday 07 April 2002 13:09, George Staikos wrote:
> Right now if the continue button is passed QString::null, it makes
> warningContinueCancel become warningYesCancel.
Right. When I changed the KMessageBox header file I added a default value for
the continue button, reasoning that nobody would explicitly send a
QString::null instead. Seems that was a very wrong assumption :-)
> This patch fixes it for me.
> Ok to apply and backport?
It only fixes the symptoms and not the cause, though.
warningContinueCancel calls warningContinueCancelList, which in turn creates a
KDialogBase with a ButtonCode 'Yes' for the continue button. There is no
predefined ButtonCode Cont available, so I wonder what the proper fix is.
Should that code be added? Then the fix can go into kdialogbase.cpp, using
the continue button properly there, and not as a customized yes button.
> I'm not sure if this was intentional or if it
I don't think this was intentional. Null strings should be handled like the
default argument I think.
> will break anything else...
Not likely, but I don't know about that. Never say never in this respect :-)
Martijn
PS: Is there a reason why you did 'buttonContinue.text() == QString::null'
instead of 'buttonContinue.text().isNull()' ? I always use the latter, so if
that has side effects I'd rather know about them...
Actually, thinking of this, you probably don't want to trigger on a null
string, but on an empty string, so you'd even need isEmpty().
More information about the kde-core-devel
mailing list