PDA

View Full Version : QLineEdit - lostFocus signal problem



Enygma
28th August 2007, 18:17
Hi guys.
I don`t remember where, but I definitely found and example on the net for validating Input on a QLineEdit.

My code is as follows:


QRegExp regexp( "([a-zA-Z0-9]+:)*[a-zA-Z0-9]+" );
QValidator *fileExtensionsValidator = new QRegExpValidator( regexp, this );

this->fileExtensionsToScan->setValidator( fileExtensionsValidator );




void MainWindow::on_fileExtensionsToScan_lostFocus(){
QString text = this->fileExtensionsToScan->text();
int pos = 0;
if ( this->fileExtensionsToScan->validator()->validate( text, pos ) != QValidator::Acceptable )
text = text.left( text.size() - 1 );

this->fileExtensionsToScan->setText( text );
}

Now... I`m using Fedora 7 with Qt4.3.1-3 installed with yum install qt4.

I`ve been requested to make a build of my application based on a static qt lib build so I downloaded the sources file 'qt4-4.3.1-3.fc7.src.rpm', built the static lib with

./configure -static -nomake demos -nomake examples -nomake tools -release -qt-zlib -qt-gif -qt-libpng -qt-libmng -qt-libjpeg -no-opengl -no-qdbus -no-cups
make
make install


build Makefile with qmake on my project file(same .pro file I use for the shared library version of my application, only that the qmake I used was from the static build)

then built my application.

After I did the above, I keep getting:

QMetaObject::connectSlotsByName: No matching signal for on_fileExtensionsToScan_lostFocus()

Tried switching to the connect method but still:

Object::connect: No such signal QLineEdit::lostFocus()
Object::connect: (sender name: 'fileExtensionsToScan')


Now... I see in present the documentation that no lostFocus() signal is defiend for QLineEdit but I think it was there in the recent earlier versions of 4.3.0 or 4.3.1.

Why does it work perfectly on my 4.3.1-3.fc7 build of Qt and on my static built version of Qt it does not?

Another problem I seem to have is that gif's file are not displayed although I used the above mentioned ./configure arguments.

Please enlighten me on this issue or at least provide me an alternative to the validation without subclassing.

Thank you guys.

jpn
28th August 2007, 20:23
QLineEdit::lostFocus() (http://doc.trolltech.com/4.3/qlineedit-qt3.html#lostFocus) is part of Qt 3 support members (http://doc.trolltech.com/4.3/qlineedit-qt3.html). As the docs mention, you should use QLineEdit::editingFinished() instead. :)

By the way, it should work when you turn Qt 3 support (http://doc.trolltech.com/4.3/qt3support.html#details) on:


QT += qt3support

Enygma
28th August 2007, 21:47
Ooooo... orcourse! :o

I had turned off qt3support :) Figured I didn't need it... guess i did after all :P

And by the way... Qt4's approach on removing lostFocus() is quite uninspired if you ask me... This is why:


void QLineEdit::editingFinished () [signal]
This signal is emitted when the Return or Enter key is pressed or the line edit loses focus. Note that if there is a validator() or inputMask() set on the line edit and enter/return is pressed, the editingFinished() signal will only be emitted if the input follows the inputMask() and the validator() returns QValidator::Acceptable.

Like... I have a validator set, right... and if the user inputs incorrect data, like "exe:txt:" this corrupts my data because no function was called to clean up the mess, why? Because editingFinished () did not get fired cause of Enter was not pressed or the input did not validate. Of course it did not validate! :eek:

So, what to do in order to avoid qt3 support being compiled? :confused:

Enygma
30th August 2007, 09:54
Any news on how to check input, even if editingFinished() did not fire?

I`m trying to understand the logic of this... :confused:

jpn
30th August 2007, 12:06
You can always catch QEvent::FocusOut (http://doc.trolltech.com/latest/qevent.html#Type-enum) by either reimplementing QWidget::focusOutEvent() or installing an event filter (http://doc.trolltech.com/latest/qobject.html#installEventFilter).

Enygma
30th August 2007, 15:40
Thanks a lot, I managed to do it using an eventFilter :p

Appreciate it jpn! ;)

weevil
17th June 2010, 20:52
Any news on how to check input, even if editingFinished() did not fire?

I`m trying to understand the logic of this... :confused:

I know this is an old thread, but I was having problems with QLineEdit's editingFinished() signal and even found a bug mention of this that was never fixed on the official nokia bugreports forum (http://bugreports.qt.nokia.com/browse/QTBUG-40). I have 3 line edits with QRegExpValidators on them, and a handler slot connected to their editingFinished() signal. The signal would sometimes not get fired when losing focus, at other times, I would have to move focus inside the dialog widget twice before two signals would be sent at once. I then found this thread and tried using the QT3 lostFocus() signal, which worked much more reliably in that the signal would fire as soon as a line edit lost focus, but it was still sending two signals at once.

I'm not sure if it's really a bug or if I'm not handling it right, but I added this to the slot connected to editingFinished() in my QDialog reimplementation,


if( receivedFocusOutSignalRecently /* a bool member set to false in the constructor */ )
return;
else {
receivedFocusOutSignalRecently = true;
QTimer::singleShot( 200, this, SLOT(resetReceivedFocusOutSignalRecently()) );
}

and made a resetReceivedFocusOutSignalRecently() slot that changed the bool to false, and got away with not having to reimplement anything. Good luck and if anyone has more to offer about this please add your thoughts.

EDIT: Also, it would be wonderful if, since they don't seem to like the lostFocus() signal, they would add an editingIncomplete() signal that fires when a line edit loses focus or the user presses enter or return with QValidator::Intermediate. The approach I took appears to be the only way to handle not leaving a line edit with unacceptable intermediate values with a validator on, which is a pretty big part of using validators in the first place. Maybe I'm missing something.