QGIS » QGIS Application

If I'm not wrong, same problem with the value relation widget.

I don't see an issue with that. The descriptions/values/second column in the edit widget field config dialog should be text as they are meant to describe the key used in the feature attribute. Hence using pure numbers there doesn't make sense to me - isn't that an edge case?

It would also be cumbersome to figure out if all descriptions are actually numbers. The key values (first column) however must be convertible to the type of the attribute. But it's not fully clear if ordering by those internal keys (the edit widget strives to hide from the user) makes sense either. Maybe that should be configurable and/or each row should have a number.

But there is another issue: currently the map is filled backwards. The description (second column) is used as key in internal QMap and the keys (first column) as values. That leads to the behaviour that duplicate descriptions (second column) make rows disappear - even if they are suppose to describe a different key (first column).

It's also why the combobox in the forms is ordered by the description and not the keys (the keys in a QMap are ordered).

But this is probably not a big issue as duplicate descriptions for the different keys don't make too much sense, but fixing it would require to migrate the project files. Maybe that should wait until we add an explicit order and maybe also grouping of values.

Jürgen Fischer wrote:

I don't see an issue with that. The descriptions/values/second column in the edit widget field config dialog should be text as they are meant to describe the key used in the feature attribute. Hence using pure numbers there doesn't make sense to me - isn't that an edge case?

It would also be cumbersome to figure out if all descriptions are actually numbers. The key values (first column) however must be convertible to the type of the attribute. But it's not fully clear if ordering by those internal keys (the edit widget strives to hide from the user) makes sense either. Maybe that should be configurable and/or each row should have a number.

But there is another issue: currently the map is filled backwards. The description (second column) is used as key in internal QMap and the keys (first column) as values. That leads to the behaviour that duplicate descriptions (second column) make rows disappear - even if they are suppose to describe a different key (first column).

It's also why the combobox in the forms is ordered by the description and not the keys (the keys in a QMap are ordered).

But this is probably not a big issue as duplicate descriptions for the different keys don't make too much sense, but fixing it would require to migrate the project files. Maybe that should wait until we add an explicit order and maybe also grouping of values.

this seems duplicate of #12494 where I gave an explanation why it is not unusual to want have a combobox with numbers. I would suggest to add an option like "list as numbers" and ignore it if the list actually does not contain just numbers (or do not allow write anything else thn numbers if the option is active).