[Qt-interest] QLabel text () returns QString::null aftersetting empty QString

[Constantin Makshin]

On Monday 13 September 2010 15:37:55 Frank Hemer wrote:
> On Monday 13 September 2010 09:10:28 Constantin Makshin wrote:
> > 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.
> 
> Thats what I would have expected.
> However a quick check after Tiagos answer revealed the following:
> 
> QLabel: returns QString::null if set to ""
> QLineEdit: never returns QString::null
> QTextEdit: never returns QString::null
> QComboBox: always returns exactly to what it was set before.
> 
> To my feel, all these elements should behave as the QComboBox. Especially when 
> I discovered that QTextEdit in Html mode for example returns changed and 
> modified html after a write-and-following-read operation and even worse, 
> changes again after a second read operation (bug was filed but not accepted) 
> which makes tracking user interaction even more difficult.
> 
> Oh well - I love qt but these little things that can be so much time 
> consuming:-(
As I said, QLabel may have that behavior because in most cases labels are rarely changed, so performance of the setText() function is somewhat less important than memory usage.

But due to the nature of QLineEdit, QTextEdit and other editable widgets using QString::null when setText("") or similar function is called may/will result in redundant and unwanted memory reallocations.

As for QTextEdit changing the HTML code, I don't know why it does that, but may be it adds/changes some information for its internal use.

Those are just my guesses, Qt developers may give a better explanation.

> Frank
> 
> > 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