From 10:00 CET Friday 22nd November we will adjust how the server works to deal with some recently reported problems. Therefore there may be a load problem, if you experience more problems than usual trying to access the forum then please PM AndyS or any of the moderators so they can inform me.
Presentation for custom data types by views
I imagine that the function “setData” can be called within the implementation for a constructor of a class which was derived from QStandardItem. The provided default functionality (including support for custom data types) would be reused then.
The available view classes provide reasonable data displays for standard data types. Additional development efforts are needed (as usual) to specify desired software behaviour for custom data types when they are finally used from the referenced data model.
- Which member functions should be overridden for extra data processing?
- Which programming approaches would you like to recommend here?
There's only 1 answer: a delegate.
a QStyledItemDelegate subclass is what you need. If it's only about displaying the data you just need to reimplement
displayText()if it's enough for you) and
sizeHint(). The other virtual methods listed in the class docs are needed to allow users to edit the data
If it's only about displaying the data you just need to reimplement paint()
- Are there any more answers (or software design constraints) to consider?
- Can the amount of “painting” be reduced because specific standard functionality can be used if the complexity level will be determined from a custom data type?
(It might occasionally be sufficient to concatenate a few numbers and strings from the data which is provided by a QVariant object from the model.)
Are there any more answers (or software design constraints) to consider?
Not really, no. Unless you go into very specific obscure cases
(It might occasionally be sufficient to concatenate a few numbers and strings from the data which is provided by a QVariant object from the model.
If the data is in a single role then
displayText()is what you are looking for instead of reimplementing the entire
Unless you go into very specific obscure cases