Presentation for custom data types by views
-
wrote on 26 Sept 2018, 18:25 last edited by
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?
-
wrote on 26 Sept 2018, 18:33 last edited by
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
paint()(ordisplayText()if it's enough for you) andsizeHint(). The other virtual methods listed in the class docs are needed to allow users to edit the data -
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
paint()(ordisplayText()if it's enough for you) andsizeHint(). The other virtual methods listed in the class docs are needed to allow users to edit the datawrote on 26 Sept 2018, 20:36 last edited byIf 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.)
-
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.)
wrote on 27 Sept 2018, 10:13 last edited by@elfring said in Presentation for custom data types by views:
Are there any more answers (or software design constraints) to consider?
Not really, no. Unless you go into very specific obscure cases
@elfring said in Presentation for custom data types by views:
(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 entirepaint() -
@elfring said in Presentation for custom data types by views:
Are there any more answers (or software design constraints) to consider?
Not really, no. Unless you go into very specific obscure cases
@elfring said in Presentation for custom data types by views:
(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 entirepaint()wrote on 27 Sept 2018, 11:02 last edited byUnless you go into very specific obscure cases
Another software design possibility would be to fiddle with proxies for data models (and their items), wouldn't it?
2/5