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!
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!
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.
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:
Qt Code:
To copy to clipboard, switch view to plain text mode
I capture the user's editing changes with the slot
Qt Code:
To copy to clipboard, switch view to plain text mode
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.
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...
Good catch. Handling that case was in my solution, though I didn't say so before.
Qt Code:
void NotQuiteHackingWindow::on_TreeWidgetInQuestion_currentItemChanged( QTreeWidgetItem *current, QTreeWidgetItem *previous) { if (previous) Ui.TreeWidgetInQuestion->closePersistentEditor(previous,2); // does nothing if none open }To copy to clipboard, switch view to plain text mode
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.
I also wonder what happens when the widget looses keyboard focus in favour of other widget... The editor should get closed then.
McKee (9th December 2006)
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.
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?
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?
Bookmarks