QStyledItemDelegate--createEditor versus setEditorData

[davethomaspilot]

I'm using a QStyledItemDelegate to implement a custom editor for a subset of columns in a QSqlRelationalTableView.

The custom editor widget needs some data that's not in the underlying model. So, I have code that queries other Sql tables to get the data needed to present the custom editor widget.

The records from the other tables are used to populate a comboBox and set the state of some pushbuttons. Selecting a different item in the combobox isn't supposed to change anything but the currentText of the combobox and the related data in the underlying model cell. The records get associated with the new combobox selection.

I'm wondering whether this code belongs in the createEditor or in setEditorData method. Or does it matter?

It seems like both are always called when a cell in the table is edited, first the createEditor, then the SetEditorData.

The example in the Qt docs (http://qt-project.org/wiki/Combo_Boxes_in_Item_Views) populates the combobox in the createEditor method, then does a selection of the combobox in the setEditorData based on what's in the underlying data model.

In my case, I need the data from the underlying data not only to select the current item in the combobox, but also for queries to other Sql queries. to get the button states. It seems like it will work either place--are there considerations for where to put the code?

Thanks,

Dave Thomas

[anda_skoa]

It mostly depends on whether the editor's contents, not just something like a selection, depends on the current value of the cell.

Say in the case of a QComboBox as the editor: if the entries in the combobox depend on the current cell value, then fill it in setEditorData. If only the current item depends on the cell data, do it in createEditor.

I wrote "mostly" because under some circumstances it doesn't matter a lot.
For example if the operation to get the entries is very fast and only a small number of entries, it doesn't likely matter if it is done on every cell update.
Or if the view is the only way to change the cell data, because then you will have almost equivalent number of calls to createEditor and setEditorData.

Cheers,
_

[davethomaspilot]

Related question--

I have column specific custom editors. Most get popuated based on the current item's value and some with other items in the same row (QSqlTableModel)

It works, but I haven't figured out how to NOT apply changes done in the editor. I could save something in the editor itself that tells my implementation of setModelData NOT to call setData, but I think there's probably something I should implement to take control of what signal does or does not get emitted when the user pushes "OK" versus "Cancel" in the custom editor.

Thanks,

Dave Thomas

[anda_skoa]

Hmm, good question.

Maybe ask this separately, i.e. in a new thread with respective title.

Cheers,
_