Re: [Interest] QLIneEdit Bug still valid ?
Op 17-7-2012 9:45, Tony Rietwyk schreef: 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 Or use QObject::blockSignals(true) on the line edit before you set the text, and the same with false afterwards. Seems easier to manage than another boolean flag somewhere, because it stays local to the place where you do the actual invokation. The flag would need code at three places: around the invokation, in the header as a member variable, and in the slot implementation when it is checked. André ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QLIneEdit Bug still valid ?
Den 17-07-2012 10:22, André Somers skrev: Op 17-7-2012 9:45, Tony Rietwyk schreef: 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 Or use QObject::blockSignals(true) on the line edit before you set the text, and the same with false afterwards. Ah, you just hit one of my pet peeves :) When doing stuff like this, create a class for it. Simpler to reuse and exception safe. For this exact problem (blockSignals) I have the code on my blog: http://www.fioniasoftware.dk/blog/?p=158 The code is trivial. But getting the habit of using objects for this kind of problem is pretty important. Bo Thorsen, Fionia Software. -- Expert Qt and C++ developer for hire Contact me if you need expert Qt help http://www.fioniasoftware.dk ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QLIneEdit Bug still valid ?
Op 19-7-2012 11:54, Bo Thorsen schreef: Den 17-07-2012 10:22, André Somers skrev: Op 17-7-2012 9:45, Tony Rietwyk schreef: 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 Or use QObject::blockSignals(true) on the line edit before you set the text, and the same with false afterwards. Ah, you just hit one of my pet peeves :) When doing stuff like this, create a class for it. Simpler to reuse and exception safe. For this exact problem (blockSignals) I have the code on my blog: http://www.fioniasoftware.dk/blog/?p=158 The code is trivial. But getting the habit of using objects for this kind of problem is pretty important. Bo Thorsen, Fionia Software. That's exactly what I do for these kinds of things, though there are many more of these pairs to be found in Qt that would benefit of a RAII class. Setting the bussy cursor and SQL transactions are just two of them, next to blocking signals of course... André ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QLIneEdit Bug still valid ?
Andre said Sent: Tuesday, 17 July 2012 6:22 PM Op 17-7-2012 9:45, Tony Rietwyk schreef: 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 Or use QObject::blockSignals(true) on the line edit before you set the text, and the same with false afterwards. Seems easier to manage than another boolean flag somewhere, because it stays local to the place where you do the actual invokation. The flag would need code at three places: around the invokation, in the header as a member variable, and in the slot implementation when it is checked. André Hi André, I don't use blockSignals because the side effects are undocumented. The problem is that ALL signals are blocked, not just the specific call to your slot. Lots of things rely on the changed signal from QLineEdit - attached models and complex widgets, like QComboBox, for example. Also, from reading the Qt code in general, there is often a complex web of internal signals between the public and private interfaces, and I've always assumed they are affected as well (?). Tony ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QLIneEdit Bug still valid ?
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é ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QLIneEdit Bug still valid ?
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... On Jul 15, 2012 4:46 PM, Petric Frank pfr...@gmx.de wrote: Hello, developing an application using Qt 4.8.2 (Linux) i stumbled over a bug with QLineEdit. I used the signal textEdited(const QString ). According to the documentation this signal should not be emitted when i change the item using setText(const QString ). Despite the spec it is emitted at caling setText. I found a bug item dated from 2010 which referring this issue: https://bugreports.qt-project.org/browse/QTBUG-15672 which is still maked as open and no progress have been made. It seems this bugreport was lost somewhere. Any hints where/how to patch the original Qt Source to fix this is welcome. regards Petric ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QLIneEdit Bug still valid ?
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é
#include QtGui
class QUppercaseValidator : public QValidator
{
public:
QUppercaseValidator(QObject *parent) : QValidator(parent) {}
virtual State validate(QString s, int ) const { fixup(s);
return Acceptable; }
virtual void fixup(QString s) const { s = s.toUpper(); }
};
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QWidget w;
QLineEdit *edit1 = new QLineEdit;
QLineEdit *edit2 = new QLineEdit;
QLabel *label = new QLabel;
//edit2-setValidator(new QUppercaseValidator(edit2));
QObject::connect(edit1, SIGNAL(textChanged(const QString )), edit2,
SLOT(setText(const QString )));
QObject::connect(edit2, SIGNAL(textEdited(const QString )), label,
SLOT(setText(const QString )));
QVBoxLayout *layout = new QVBoxLayout;
layout-addWidget(edit1);
layout-addWidget(edit2);
layout-addWidget(label);
w.setLayout(layout);
w.show();
return a.exec();
}___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QLIneEdit Bug still valid ?
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é ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QLIneEdit Bug still valid ?
I can't say for sure, but most probably yes. 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é signature.asc Description: OpenPGP digital signature ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QLIneEdit Bug still valid ?
Hello David, Am Sonntag, 15. Juli 2012, 15:36:19 schrieb David Boosalis: Hi Petric. SInce your changing the text in your code, as a work around why not disconnect the signal, change the text, then reconnect the signal Thats alike what i did currently. It is in my opinion a crude solution. If you have more than a couple of line edits in your applications you have a lot mode uneccessary code in your application. But wouldn't it better to be fixed the library itself ? regards Petric On Sun, Jul 15, 2012 at 5:45 AM, Petric Frank pfr...@gmx.de wrote: Hello, developing an application using Qt 4.8.2 (Linux) i stumbled over a bug with QLineEdit. I used the signal textEdited(const QString ). According to the documentation this signal should not be emitted when i change the item using setText(const QString ). Despite the spec it is emitted at caling setText. I found a bug item dated from 2010 which referring this issue: https://bugreports.qt-project.org/browse/QTBUG-15672 which is still maked as open and no progress have been made. It seems this bugreport was lost somewhere. Any hints where/how to patch the original Qt Source to fix this is welcome. regards Petric ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
