[Interest] QLIneEdit Bug still valid ?

[Tony Rietwyk]

Hi, 

A much easier solution to disconnecting the signals, is to set a flag before calling setText, then check that in the slot.  

Hope that helps, 

Tony

> -----Original Message-----
> From: interest-bounces+tony=rightsoft.com.au at qt-project.org
> [mailto:interest-bounces+tony=rightsoft.com.au at qt-project.org] On Behalf
> Of Constantin Makshin
> Sent: Tuesday, 17 July 2012 4:53 PM
> To: Qt Interest
> Subject: Re: [Interest] QLIneEdit Bug still valid ?
> 
> Both textChanged() and textEdited() signals are emitted from the
> QLineControl::finishChange() function which is called by
> QLineControl::internalSetText(), so the order of these signals is always the
> same   textEdited(), then textChanged(). However, when the validator
> modifies QLineEdit's contents, there seems to be no way to tell whether the
> change was caused by the user or a call to QLineEdit::setText().
> 
> So, after some thinking, I doubt one can easily make a reliable fix for this bug.
> But is it really so important/annoying? Validators are meant to check and fix
> user input because users are not very reliable in terms of input's correctness
> (there's relatively high chance of hitting a wrong key/button, for example),
> but the program always knows (or, at least, should know) the format of the
> data it expects. Considering this, IMHO it looks a bit strange to pass an
> arbitrary text to setText() in the hope the validator will fix it instead of
> explicitly specifying/preparing a correct string and passing it to that method.
> 
> While it obviously is a bug, I'm not sure benefits of fixing it are worth the
> efforts needed to develop a good (= reliable, without breaking API and ABI
> compatibility) fix.
> 
> On 07/17/2012 10:13 AM, Andre Somers wrote:
> > Op 17-7-2012 2:51, Constantin Makshin schreef:
> >> I can't say for sure, but most probably yes.
> > You'd have to check to see if that does not block the emission of the
> > signal then after the user edited the text. Does anyone know what the
> > signal emission order _should_ be in case where a user edits the line
> > edit, and the validator corrects that input?
> >
> > Andr
> >
> >> On 07/17/2012 04:10 AM, Petric Frank wrote:
> >>> Hello Ren ,
> >>>
> >>> so patching this location to pass false as additional third
> >>> parameter should fix the issue, right ?
> >>>
> >>> regards
> >>>   Petric
> >>>
> >>> Am Dienstag, 17. Juli 2012, 01:06:43 schrieb Constantin Makshin:
> >>>> It works incorrectly only when the validator changes the text.
> >>>>
> >>>> The cause is QLineControl::fixup()
> >>>> (src/gui/widgets/qlinecontrol.cpp,
> >>>> line 387)   it calls QLineControl::internalSetText() with only 2
> >>>> parameters, omitting the one that controls emission of the
> >>>> textEdited() signal. And since that parameter defaults to 'true', you get
> what you get.
> >>>>
> >>>> On 07/16/2012 03:38 PM, R. Reucher wrote:
> >>>>> On Monday 16 July 2012 09:14:31 Constantin Makshin wrote:
> >>>>>> Functions you are interested in are (line numbers are taken from
> >>>>>> the code in the Git repository):
> >>>>>> src/gui/widgets/qlineedit.cpp, line 383 (QLineEdit::setText)
> >>>>>> src/gui/widgets/qlinecontrol_p.h, line 213
> >>>>>> (QLineControl::setText) src/gui/widgets/qlinecontrol.cpp, line
> >>>>>> 676
> >>>>>> (QLineControl::internalSetText) src/gui/widgets/qlinecontrol.cpp,
> >>>>>> line
> >>>>>> 620 (QLineControl::finishChange)
> >>>>>>
> >>>>>> Nothing looks wrong there...
> >>>>> Yeah, I also recall it was working correctly when I used it last time...
> >>>>>
> >>>>> However, the example acts "wrongly", but it somehow only happens
> >>>>> when the validator is set. The attached example (w/o the
> >>>>> validator) works correctly.
> >>>>>
> >>>>> HTH, Ren