QTreeView search

[jpujolf]

Hi folks,

I don't know is this question was asked before. I haven't found it on the forum, so here I am.

I'm having trouble with my QtreeView. I'm showing data in multiple columns, acting as a "QTableView with groups". No edit is available, only navigation.

Even in the simpler case with no groups ( so QTreeView looks exactly like a QTableView ) when user selects a cell and begins typing starts "navigation" through data, as an auto-search. I think that's Qt's behaviour, I coded no line to achieve this. Simply it worked...

But now does'nt work anymore. User begins to type and only the first 2 chars they type move selection. After 2 chars it stops moving.

Why ? There is a role in the model I've to implement ? A flag I must set ? I cannot find nothing in documentation :crying: ( perhaps I'm not searching in the rigth direction... )

Any idea ?

[aamer4yu]

But now does'nt work anymore. User begins to type and only the first 2 chars they type move selection
what state is NOW ? i mean did u change anything in the code ?

also what is the speed of typing ? usually the moment you delay typing, the text entered till that time is searched.

[jpujolf]

Sorry for the delay. Weekend... :)


what state is NOW ? i mean did u change anything in the code ?


I've found a workaround. Now is finally working, but with some hacking. I've been looking inside QTreeView's "keyboardSearch" method. It moves current view's index when necessary, but it also moves to the first column. I don't know why...

Perhaps an example would be clearer. Image a "simple" tree structure like this ( it's shown on screen as a plain table ) :

ROOT
|---- Child 0 ( 5 columns )
|---- Child 1 ( 5 columns )
|---- Child 2 ( 5 columns )
...

If you are selecting third column, and you move up / down with arrows, you may stay on third column. I cannot find the reason because trolls decided to switch on every row change to column 0. So I made this hack :



void keyboardSearch ( const QString & search )
{
int iCol = currentIndex().column();
QTreeView::keyboardSearch ( search );
setCurrentIndex ( model()->sibling ( currentIndex().row(), iCol, currentIndex() ) );
}


Also, I'm doing some minor changes to even method, to catch Left/Right, PgUp/PgDown, Home/End keys and allow user to move in a logical way.



void SelectCell ( int Key )
{
int iCol = 0;
switch ( Key )
{
case Qt::Key_Right : iCol = 1; break;
case Qt::Key_Left : iCol = -1; break;
}

QModelIndex AUX = currentIndex ();
iCol = qMax ( 0, qMin ( AUX.column() + iCol, model()->columnCount() - 1 ) );
setCurrentIndex ( model()->sibling ( AUX.row(), iCol, currentIndex() ) );
};

bool event ( QEvent * qe )
{
if ( qe->type() != QEvent::KeyPress )
return QTreeView::event ( qe );

QKeyEvent * ke = dynamic_cast<QKeyEvent *>(qe);
switch ( ke->key() )
{
case Qt::Key_Right :
case Qt::Key_Left :
{
SelectCell ( ke->key() );
qe->accept();
return true;
}
case Qt::Key_Up :
case Qt::Key_Down :
case Qt::Key_PageUp :
case Qt::Key_PageDown :
case Qt::Key_Home :
case Qt::Key_End :
{
int iCol = currentIndex().column();
if ( inherited::event ( qe ) )
{
setCurrentIndex ( model()->sibling ( currentIndex().row(), iCol, currentIndex() ) );
return true;
}
return false;
}
break;

<other stuff ...>

return QTreeView::event ( qe );
}
}


I wonder about Qt's default behavior :confused:. I cannot find the reason because they consider better to "jump" to the first column every time you change the row of the index.

They must, at least, consider this option. In many cases ( a great % of times ) when you show a tree with multiple columns, the data has the same number of columns in all the rows.



also what is the speed of typing ? usually the moment you delay typing, the text entered till that time is searched.

It's not an speed problem, I've done this on my program startup :

QApplication::setKeyboardInputInterval ( 1000 );

So 1 second between keystrokes is sufficient enough for my users...

[aamer4yu]

What is your tree widget's QAbstractItemView::selectionBehavior set to ?
i am not sure if in a tree u can select single cell...

but seeing ur problem, a tableview seems better... even in qt demo example, you can move the cells with keyboard in the way you want to...ie., maintain the previous row and column..

[jpujolf]

What is your tree widget's QAbstractItemView::selectionBehavior set to ?
i am not sure if in a tree u can select single cell...


Yes, we can :D ( Sorry, I've heard too much times that phrase... )

I've set it to single rows. If you test on any QTreeView, when you select a cell with mouse, a dotted square is painted around that cell and if you call currentIndex(), column is set to the one you selected.

My complains come because even when selecting entire rows, the column where I've clicked MUST persist even if I change to another row, or not ?

If not, "keyboardSearch" method only is granted to work for first column searches.



but seeing ur problem, a tableview seems better... even in qt demo example, you can move the cells with keyboard in the way you want to...ie., maintain the previous row and column..

It must be better if all the cases I've had where the extreme case I've shown ( a simple tree structure ). But a QTableView is not an option, because I've to show tabular data, but user can "group by column" with many levels. So I've to expand/collapse rows,as show in attached picture.

I will report that to trolls to suggest if is acceptable to them to add new behavior options for QTreeView. You must think that, in the extreme case, a QTreeView looks like a QTableView and must act a s a QTableView.

As you've seen on my last post, I've solved it with some hacking. I answered myself to legate a possible solution to other people with the same problem. I usually ask for help here, but if my experiences could be useful for others...

[aamer4yu]

You are right with your doubt..
The behaviour can be seen in Qt demo DirView example too...
though sometime one will ignore the dotted rect, as it is hard to see over a selected area.

[jpujolf]

You are right with your doubt..
The behaviour can be seen in Qt demo DirView example too...
though sometime one will ignore the dotted rect, as it is hard to see over a selected area.

You're right !! That's the reason I've open another thread, asking for one solution to that too-thin dotted square ( thanls for your answer, I will try it )

http://www.qtcentre.org/forum/f-qt-programming-2/t-qtreeview-selection-style--19181.html#post94657