[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