You are not logged in.

QComboBox - how to detect editing finished?

wdezell

Beginner

  • "wdezell" started this thread

Posts: 12

  • Send private message

1

Wednesday, April 16th 2008, 9:24pm

QComboBox - how to detect editing finished?

I have a requirement to display text retrieved from a database based on matching against a QString extracted from an editable QComboBox.

'currentIndexChanged()' is a usable signal I can catch to handle changes resulting from list item selection but I'm having problems with the editable lineEdit portion of the combo box. There is no 'editingFinished()' signal on the combo box as for QLineEdit nor even a 'lostFocus' signal which I could use to grab the currentText(). The 'editTextChanged()' signal is a poor choice since it is firing a SQL query for me on every keypress.

Can anyone suggest a better approach for how I may detect just when editing is done and invoke my query?

Thanks, Bill.

stinny

Beginner

  • "stinny" is male

Posts: 28

Location: Prague

Occupation: CS student

  • Send private message

2

Wednesday, April 16th 2008, 10:40pm

RE: QComboBox - how to detect editing finished?

You can start SQL search, say, 1 second after last editTextChanged() was emitted. Thus You should do something like

Source code

 
1
2
3
4

timer->setSingleShot( true );
timer->setInterval( 1000 );
connect( comboBox, SIGNAL(editTextChanged(QString)), timer, SLOT(start()) );
connect( timer, SIGNAL(timeout()), this, SLOT(performHugeSQLQuery()) );
Your searching will be a little delayed, but requiring user to type the expression that will be sought in database and [/B]then clicking somewhere else (which is not needed when You select one of the predefined values in QComboBox) is not very user-friendly. I am afraid that there is no better way to look in Your user mind and find out whether he has finished typing or not :-)

wdezell

Beginner

  • "wdezell" started this thread

Posts: 12

  • Send private message

3

Wednesday, April 16th 2008, 11:10pm

That's not as elegant as I'd hoped for but is a clever workaround better than what I'm presently doing. In my application it should work just fine. Thanks so much for the help.

T.M.F.

Trainee

  • "T.M.F." is male

Posts: 151

  • Send private message

4

Thursday, April 17th 2008, 1:44am

You can search database after any change in editor, it could be easy and fast, because any new letter just narrow your records. Another possibility is to use Enter key. So user enters text, and later must press the Enter key to start search. I think that the first option is better.

This post has been edited 1 times, last edit by "T.M.F." (Apr 17th 2008, 1:45am)

wdezell

Beginner

  • "wdezell" started this thread

Posts: 12

  • Send private message

5

Thursday, April 17th 2008, 1:54am

Your first suggestion is essentially how my code was functioning and, true, it was very fast with my test dataset on my local server.

My worry is the excessive number of queries that execute (one per keypress). I am concerned about per-query execution time as the record count grows huge and network latencies/traffic given that the production database will not be on the same box (possibly even across the country). Have you seen any performance examples in similar configurations?

T.M.F.

Trainee

  • "T.M.F." is male

Posts: 151

  • Send private message

6

Thursday, April 17th 2008, 2:20am

Yes, you can expect some performance issues. So it is extremly important to know how many records you will process? If you choose QComboBox I suppose that not too many. So it will be working ok. You can consider downloading the whole table ans search it offline to speed up the process and to reduce total network load. Or possibly download records in another thread, so user will see them progresively. In fact you have to do that because othercase network problems will be looking for user as application's hangs.

wdezell

Beginner

  • "wdezell" started this thread

Posts: 12

  • Send private message

7

Thursday, April 17th 2008, 3:09pm

The datasets may potentially be huge but the combobox lists are filtered based upon some initial criteria. I'm trying to find some kind of balance between the hand-holding intuitive user interface I want to build and an app that performs responsive enough.

For now I've implemented the one-shot delays in a manner allowing easy adjustment of the delay. Once I field the app to the users and get some real datasets I plan to run the delay down to mimic the original timer-less implementation and try and get some performance metrics. If I can remember I'll post findings here.

Thanks for the guidance.