QListWidget : avoid click before selecting

[henk_marsman]

Hi,

I'm using a QListWidget to show a number of records. Running this on my E71 (non-touch screen), before I can scroll through the list, I need to click the list (even if it has focus) and the menu changes from 'Options' to 'Done'. I saw this behaviour also in one of the examples, called qts60sms.
This is of course very annoying because if the only widget on my screen is a list, I do not want to have to click this first and then choose 'done' to get out of it.
Is this behaviour unavoidable when using QT on a non-touch device ? Or is there a workaround ? Should I avoid the QListWidget ?

Another thing also : my buttons in the qt-based apps have a different style than the the native apps. How come ?

Thanks a lot for any input on these questions!

Henk

[petri.aijo]

Have you found solution to this problem? I also have this same problem and it is visible in emulator too.

Edit: i'm using QT 4.6.0 and carbide.c++ ver 2.3.0.

Thanks in advance,
Petri

[jp4symbian]

Hey guys,

Has anyone of you managed to solve this problem...Kindly post the solution in case anyone has it..
Thanks in advance.

[henk_marsman]

Hi

yes, there is a solution : forget the gui builder and handle the key events yourself.
E.g.

void MyListTab::keyPressEvent(QKeyEvent *event)
{
    switch (event->key()) {
    case Qt::Key_Up:
        if (currentRow() == 0) {
            setCurrentRow(count() - 1);
        } else {
            setCurrentRow(currentRow() - 1);
        }
        break;
    case Qt::Key_Down:
        if (currentRow() == (count() - 1)) {
            setCurrentRow(0);
        } else {
            setCurrentRow(currentRow() + 1);
        }
        break;
    case Qt::Key_Select:
        openItem(currentItem());
    default:
        QListWidget::keyPressEvent(event);
        break;
    }
}

I now have another problem with timers (will post this separately) : in the emulator it works perfectly, on the device it get's stuck.

cheers

Henk

[divanov]

This is very strange solution. Did you try to use QWidget::setEditFocus() for QListWidget?

[jp4symbian]

Hey Henk,

I thing you have subclassed your class "MyListTab". That is why you can write this: QListWidget::keyPressEvent(event)

But I am not doing any subclassing. Hence I cannot call this function. My class derives from QMainWindow & I am simply creating a list widget in that.

That is the reason I do not get any key events once the left softkey changes from 'Options' to 'Done'.


@divanov: QWidget::setEditFocus() doesnt work for me!

[divanov]

I thing you have subclassed your class "MyListTab". That is why you can write this: QListWidget::keyPressEvent(event)

But I am not doing any subclassing. Hence I cannot call this function. My class derives from QMainWindow & I am simply creating a list widget in that.

You can use event filter in this case
http://doc.trolltech.com/4.6/eventsandfilters.html

[jp4symbian]

You can use event filter in this case
http://doc.trolltech.com/4.6/eventsandfilters.html

I have tried to implement event filters. But now the problem is that once I handle the Key event for the "Qt::Key_Select", no further key events are being processed by the ListWidget (up/down arrow keys).

Even on returning false or QMainWindow::eventFilter(obj, event);, the key event isnt processed by the List Widget.

Note: I have overriden 'keyPressEvent' in my class, so execution goes there which means that the MainWindow is handling this event whereas the event should be handled by the List Widget. Is there any way to divert the key events to be handled by the list widget?

Any suggestions?

[petri.aijo]

This is very strange solution. Did you try to use QWidget::setEditFocus() for QListWidget?

This solved my problem.
Thank you very much.

[jp4symbian]

Finally I have got it working by sub-classing my List Widget and overriding the "keyPressEvent" as it is done above.
Thanks henk_marsman.

[petri.aijo]

This is very strange solution. Did you try to use QWidget::setEditFocus() for QListWidget?

Just for the record, it is not mandatory to make any special key event handling to do line select in listWidget.

	
//connect is the key for the "select"-button to work
connect(listWidget, SIGNAL(itemActivated(QListWidgetItem*)), this, SLOT(selectAction(QListWidgetItem*)));

//setEditFocus(true) removes the needed first click that was mentioned in the first post.
//Now "up" and "down"-button presses moves the selection in listWidget.
listWidget->setEditFocus(true);

//remember to declare selectAction(QListWidgetItem* selectedItem) as slot!
void someClass::selectAction(QListWidgetItem* selectedItem){
	//do something
}

[jp4symbian]

Thanks a lot for this "quick" solution. But I feel sub-classing gives a clearer interface.

Just for the record, it is not mandatory to make any special key event handling to do line select in listWidget.

	
//connect is the key for the "select"-button to work
connect(listWidget, SIGNAL(itemActivated(QListWidgetItem*)), this, SLOT(selectAction(QListWidgetItem*)));

//setEditFocus(true) removes the needed first click that was mentioned in the first post.
//Now "up" and "down"-button presses moves the selection in listWidget.
listWidget->setEditFocus(true);

//remember to declare selectAction(QListWidgetItem* selectedItem) as slot!
void someClass::selectAction(QListWidgetItem* selectedItem){
	//do something
}

[divanov]

Thanks a lot for this "quick" solution. But I feel sub-classing gives a clearer interface.

Reimplementing of key event in this case is dirty hack and should be avoided.

[jp4symbian]

You mean overriding the "keyPressEvent" for a widget is not appropriate??
But isn't sub-classing meant for this..

Moreover the default functioning of the List Widget is quite confusing. The user first presses the Ok key to enable item scrolling of the List Widget.(That is when the 'Options' soft key changes to 'Done' ). Then he needs to press the Done key again.

I thought the sub-classing made the interface better..Please could you clear my doubts?

Reimplementing of key event in this case is dirty hack and should be avoided.

[divanov]

You mean overriding the "keyPressEvent" for a widget is not appropriate??
But isn't sub-classing meant for this..

The proper alternative to overriding key event handler was mentioned in this post.