QTreeWidget item editing: want column specificity

[McKee]

I am using QTreeWidget, such a nice convenience class for us porters from Qt 3 -> 4, but I am unable to find a way to make a particular column of a QTreeWidgetItem editable while the other columns are not. Currently, I make an item editable upon creation like this:



item->setFlags(item->flags() | Qt::ItemIsEditable);


But this makes all the columns editable, whereas I just want to be able to edit, say, column 2. I tried not setting the item flags as above, and instead calling



tree_widget->editItem(item,2);


in my slot for itemDoubleClicked(), after checking that the double-clicked column is 2. But that fails because the item must have its editable flag set to true for editItem() to succeed.

What I'd like to see is a column-specific QTreeWidgetItem::setFlags() function, i.e. QTreeWidgetItem::setFlags(Qt::ItemFlags flags, int col = -1). How to get the desired effect without resorting to subclassing? Ask TrollTech for an enhancement?

I'm at Qt 4.2.1.

Advice, anyone?

thanks,
McKee

[wysota]

Use the model-view approach. You can operate on each column separately there.

[McKee]

I found a better solution: leave the QTreeWidgetItem objects un-editable, and call the following convenience functions provided by QTreeWidget:


tree_widget->openPersistentEditor(item,col);
...
tree_widget->closePersistentEditor(item,col);

The item and column are provided by the signals I capture with slots in my parent form. I make the calls only for the target column, thus achieving the column-specificity I was after. For my app I am using signal
QTreeWidget::itemDoubleClicked(QTreeWidgetItem*,in t) to trigger editing.

So no fooling with QTreeWidgetItem flags, just starting/stopping the editor explicitly, and using the persistent one.

McKee

[wysota]

I don't know if that solution is better :)

[McKee]

That's the difference between an expert (you) and a beginner (me). The latter is ebullient when he spots a "solution". ;)

Thanks for the replies!

[Brandybuck]

In the long run, the model/view approach is best. Then you can have your model's flag() function not make the one column editable.

The convenience widgets should not be treated as the Qt4 version of the Qt3 item views. They were meant for small simple views. That you're trying to make some columns editable and others not, tells me that you're trying to make QTreeWidget do too much.

[McKee]

Point taken; thanks.

But I succeeded in getting the functionality I needed with just +5 lines of code, using a function provided by QTreeWidget itself, not some hack:


void QTreeWidget::openPersistentEditor(QTreeWidgetItem* item,int column)

I capture the user's editing changes with the slot


void QTreeWidget::itemChanged(QTreeWidgetItem * item, int column)

So I feel I was not trying to do too much with the convenience class. I was just slow to find the solution. This feature of my app is a small, simple sidelight, not a central, expandible effort, so I'm done and it's stable. Movin' on ...

But thanks for the advice.

[wysota]

What if you just click or tab to another cell of the widget without changing the contents? Does the editor get closed? I still think you are "hacking" the widget a little...

[McKee]

Good catch. Handling that case was in my solution, though I didn't say so before.


void NotQuiteHackingWindow::on_TreeWidgetInQuestion_cur rentItemChanged( QTreeWidgetItem *current, QTreeWidgetItem *previous)
{
if (previous)
Ui.TreeWidgetInQuestion->closePersistentEditor(previous,2); // does nothing if none open
}

Line 3 isn't really necessary. And the slot is connected automatically by the UI setup function -- no code needed for that.

Ok, I concede your point. Thanks.

[wysota]

I also wonder what happens when the widget looses keyboard focus in favour of other widget... The editor should get closed then.

[McKee]

Good thought. I checked that case, and the behaviour seems ideal. If the item is open but no changes have been made, the editor persists in that when the QTableWidget gets focus back, the item is still in edit mode. But if there has been a change to the item when QTableWidget loses focus, it emits itemChanged() and closes the persistent editor. I'm :) with that.

[wysota]

This is a strange behaviour. If a widget loses focus, the editor should be closed. Imagine you have 10 such tables. If you change focus between them, you'll soon have 10 editors open. Is that really what you want?

[McKee]

For the library, that may be an issue. But for my app, it's not. I have many tables, yes, but only 2 are editable, and the "keep-editor-open-if no-change-after-focus-loss" behaviour, though strange, is in my case preferable. It provides more of a "where was I" context when the user returns focus to the widget. If I did need to rectify the strangeness, I suppose there's a way to capture an event for the table widget losing focus and close the editor explcitly. But I need not discover it at this point.

Have we wrung this thread dry yet?