[Qt-interest] QLabel text () returns QString::null aftersetting empty QString
Constantin Makshin
cmakshin at gmail.com
Mon Sep 13 09:10:28 CEST 2010
If I understood you correctly, you want to check if widget contents (text) have been changed, right? Then you could use something like this:
if (!(oldText.isEmpty() && newText.isEmpty()) // (1)
&& newText != oldText)
{
// ...
}
(1) prevents the code from being triggered in your 'QString("") != QString::null' case.
I guess widgets may prefer QString::null to QString("") because the former is shared between all QString objects and therefore helps to save some memory — the fastest way to make a string empty without memory reallocations is to set both the first character and length property to zero, but since some widgets like labels are usually used to display some static or rarely-changed text, that truncation would be a waste of memory.
On Thursday 09 September 2010 23:18:30 Frank Hemer wrote:
> On Thursday 09 September 2010 19:23:43 Scott Aron Bloom wrote:
> > -----Original Message-----
> > From: qt-interest-bounces at trolltech.com
> > [mailto:qt-interest-bounces at trolltech.com] On Behalf Of Frank Hemer Sent:
> > Thursday, September 09, 2010 10:19 AM
> > To: qt-interest at trolltech.com
> > Subject: Re: [Qt-interest] QLabel text () returns QString::null
> > aftersetting empty QString
> >
> > On Thursday 09 September 2010 19:07:25 Thiago Macieira wrote:
> > > Em Quinta-feira 09 Setembro 2010, às 15:38:33, Frank Hemer escreveu:
> > > > Is the behavior mentioned in the subject intended/known or is it a bug
> > > > that needs to be filed?
> > >
> > > Unless otherwise specified in the documentation, you shouldn't rely on
> > > methods keeping the null-vs-empty setting.
> >
> > Thanx for clearing this.
> >
> > However this makes it impossible to track if objects (QLabel, QLineEdit,
> > QTextEdit and probably others) have been modified bec. comparing former
> > state to later state is no more possible:-( ... for code that
> > differentiates between QString ("") and QString::null ...
> >
> > Frank
> > ------------------------------
> >
> > Not unless you simply tag it when you watch for the textChanged signals..
> > Though for QLabel, the user cant modify the label directlky so Im not sure
> > how it would be so difficult to track.
> >
> > Scott
>
> Well ... thats just the point: QLabel is not a real problem here as it can be
> worked around by adding tracking code ... but what about the other QWidget
> derived classes that return QString? Using textChanged is of no use here
> since it already hides the possible 'null' string.
>
> I'm using this in a scripting environment - the only way would be to derive
> from the base class and overwrite _ALL_ methods that somehow modify the
> contained string ... I'm sure it is way easier to fix the class itself to
> return what it was set to before ...
>
> Frank
More information about the Qt-interest-old
mailing list