QSqlTableModel
-
@JonB said in QSqlTableModel:
Somewhere in the existing Qt code for data(DisplayRole) there must be the equivalent of QString::arg(char format = 'g')
No, data is converted to string to represent it inside
QStyledItemDelegate::displayText, nowhere else (and it usesQLocale::toStringinstead of the C-locale-onlyQString::number). The model holds the data in the native format and never cares about how it is represented to the userYour code is all in a QStyledItemDelegate for a QTableView or similar
Yes, my code is for the model-view-delegate architecture
I do not want special code for displaying a number in a view, I want it just as much for displaying it in, say, a label, or hundreds of other places
Then it's the final user that has to take care of knowing how to convert a double to string. Exactly because of the reason you mentioned. the model is agnostic to what you use it in/for
@VRonin said in QSqlTableModel:
No, data is converted to string to represent it inside QStyledItemDelegate::displayText, nowhere else. The model holds the data in the native format and never cares about how it is represented to the user
If you are saying that
QStyledItemDelegate::displayTextdoes its own conversion offdata(EditRole)then I don't get it, because I changedata(DisplayRole)for numbers and they come out reflecting that in table views? Unless you are saying I am going mad.If the model never cares about representation to the user, what is the purpose of
DisplayRole? (Or, for that matter,FontRoleetc. Indeed, why does the model'sdata()even offer or get called for such roles?) -
For all native Qt Models
EditRoleandDisplayRoleare one and the same. They never get separated. They are distinct only if you implement a custom model.QStyledItemDelegate::displayTextdoes its own conversion offdata(DisplayRole)it never cares aboutEditRole(unless you have some custom implementation that passes editrole to it)what is the purpose of DisplayRole?
The most iconic example of the purpose is thinking abount excel/libre office calc: edit role is the formula, display role is the result of that formula. You can never change the result directly when you modify a cell. You always change the formula (edit role) then the program calculates the result and shows it in dispaly role. The result of
=2+2(string in editrole) is stored as int/double in the displayrole. The delegate then takes care of taking that number and converting it to something that can be printed on the screen"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
For all native Qt Models
EditRoleandDisplayRoleare one and the same. They never get separated. They are distinct only if you implement a custom model.QStyledItemDelegate::displayTextdoes its own conversion offdata(DisplayRole)it never cares aboutEditRole(unless you have some custom implementation that passes editrole to it)what is the purpose of DisplayRole?
The most iconic example of the purpose is thinking abount excel/libre office calc: edit role is the formula, display role is the result of that formula. You can never change the result directly when you modify a cell. You always change the formula (edit role) then the program calculates the result and shows it in dispaly role. The result of
=2+2(string in editrole) is stored as int/double in the displayrole. The delegate then takes care of taking that number and converting it to something that can be printed on the screen@VRonin said in QSqlTableModel:
QStyledItemDelegate::displayTextdoes its own conversion offdata(DisplayRole)it never cares aboutEditRoleThat is very interesting. So when (for right or for wrong) I made my
data(DisplayRole)of a floating produce the format I wanted (fformat, 2 decimal places) as a string,displayTextsaw a string instead of a number and passed it through without its own formatting, that's why it came out as it did.I know about the spreadsheet case. It is "unusual", compared to 99% of cases. I thought
DisplayRolewas supposed to return the desired string for the default way you wanted the data output, hence why I did it that way for the floating point numbers. I think it was the very first area I did with Qt/PyQt, and I didn't know what you are saying now.Although I know this conversation has been long, I hope @Xilit, the OP, won't mind as it's actually useful for him to see this stuff.
So my last question to @VRonin is: why are there all the other "presentational" roles (
FontRole,TextAlignmentRole,ForegroundRoleetc.)? If you are so keen that "The model [...] never cares about how it is represented to the user", why do you let the model provide/handle those? Even worse,data()returns types likeQFontandQBrushfor these (not even just a "symbolic" indicator), which is all to do with the presentation to the user. -
@VRonin said in QSqlTableModel:
QStyledItemDelegate::displayTextdoes its own conversion offdata(DisplayRole)it never cares aboutEditRoleThat is very interesting. So when (for right or for wrong) I made my
data(DisplayRole)of a floating produce the format I wanted (fformat, 2 decimal places) as a string,displayTextsaw a string instead of a number and passed it through without its own formatting, that's why it came out as it did.I know about the spreadsheet case. It is "unusual", compared to 99% of cases. I thought
DisplayRolewas supposed to return the desired string for the default way you wanted the data output, hence why I did it that way for the floating point numbers. I think it was the very first area I did with Qt/PyQt, and I didn't know what you are saying now.Although I know this conversation has been long, I hope @Xilit, the OP, won't mind as it's actually useful for him to see this stuff.
So my last question to @VRonin is: why are there all the other "presentational" roles (
FontRole,TextAlignmentRole,ForegroundRoleetc.)? If you are so keen that "The model [...] never cares about how it is represented to the user", why do you let the model provide/handle those? Even worse,data()returns types likeQFontandQBrushfor these (not even just a "symbolic" indicator), which is all to do with the presentation to the user.@JonB said in QSqlTableModel:
I hope @Xilit, the OP, won't mind as it's actually useful for him to see this stuff.
Nope! Of course I don't mind! Rather I vote for this disscusion! It is really useful information. I'll read all this stuff very carefully after I read all information about model by links above. Then I'll read this comments because I never understand
DisplayRoleproperly.(( -
@JonB said in QSqlTableModel:
I hope @Xilit, the OP, won't mind as it's actually useful for him to see this stuff.
Nope! Of course I don't mind! Rather I vote for this disscusion! It is really useful information. I'll read all this stuff very carefully after I read all information about model by links above. Then I'll read this comments because I never understand
DisplayRoleproperly.((There are really tons of information on tutorials.))) In order not to sink there I decided to start my project from scretch and make this tutorial step by step. But now I stand at a crossroads what project architecture should I choose. I prepare one picture for you to show you what I mean.
I want to choose scheme number 6 and implement it in my project. I need universal solution to show tables from DB and lists in future. Maybe list, I'm not sure, that's why I want to create universal model (if it's possible). But for now I want to show table to user with my data from database table.
If it's not to hard for you to say what scheme (1-6) is incorrect at all and what scheme is preferable to implement in my situation.
Thank you!
-
There are really tons of information on tutorials.))) In order not to sink there I decided to start my project from scretch and make this tutorial step by step. But now I stand at a crossroads what project architecture should I choose. I prepare one picture for you to show you what I mean.
I want to choose scheme number 6 and implement it in my project. I need universal solution to show tables from DB and lists in future. Maybe list, I'm not sure, that's why I want to create universal model (if it's possible). But for now I want to show table to user with my data from database table.
If it's not to hard for you to say what scheme (1-6) is incorrect at all and what scheme is preferable to implement in my situation.
Thank you!
-
Follow the chain up, QSqlTableModel is already a subclass of QAbstractTableModel.
As for the delegate, it's a QStyledItemDelegate that is used by default by the view to render the table's content.
-
Follow the chain up, QSqlTableModel is already a subclass of QAbstractTableModel.
As for the delegate, it's a QStyledItemDelegate that is used by default by the view to render the table's content.
"QStyledItemDelegate that is used by default by the view"
Yes I know that. Tutorial says that if I want to make my own view I need to reimplement
QStyledItemDelegateby sybclassing it. If you see what @VRonin said me to do is:
"Just subclass QStyledItemDelegate and override displayText:". So does this scheme correct?
P.S. Sorry for my persistance but tommorow I start working with my project so I want to understand all the details. Thank you!
-
No, QStyledItemDelegate is at the view level, or maybe between the view and the model since it uses it to render something from the data in the model.
-
No, QStyledItemDelegate is at the view level, or maybe between the view and the model since it uses it to render something from the data in the model.
Yes it is clear. My main question is where should I connect (pass) my delegat? I created MyDelegate.cpp, describe what I want and then pass it / connect it in QSqlTableModel.cpp? That I discribed in scheme above. This is the simpliest case. Of course there is another possibility to create MyClass.cpp and pass to this class my model and delegate, but now I'm talking about simple one. If all my app is just show info from DB can I pass my delegate to QSqlTableModel.cpp?
-
The delegate has nothing to do directly with the model. You set the delegate on the view with setItemDelegate or one of its more precise sibling.
-
The delegate has nothing to do directly with the model. You set the delegate on the view with setItemDelegate or one of its more precise sibling.
