Bug report #6515

values in "value map" edit widget are always treated as text

Added by Giovanni Manghi almost 7 years ago. Updated 7 months ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Edit widget
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:end of life
Crashes QGIS or corrupts data:No Copied to github as #:15732

Description

even if the values are numbers, resulting in an incorrect order.

An option to allow treat the values as numbers should be added.

Tested on 1.8 and Windows.


Related issues

Related to QGIS Application - Bug report #12387: Value map fields are always treated as text Closed 2015-03-17
Duplicated by QGIS Application - Feature request #12313: Order of values in ValueMap Closed 2015-03-04

History

#1 Updated by Nathan Woodrow over 6 years ago

  • Assignee set to Nathan Woodrow

#2 Updated by Giovanni Manghi over 5 years ago

  • Category changed from GUI to Edit widget
  • Assignee deleted (Nathan Woodrow)
  • Target version changed from Version 2.0.0 to Future Release - Nice to have

#3 Updated by matteo ghetta about 5 years ago

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

#4 Updated by Jürgen Fischer over 4 years ago

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.

#5 Updated by Giovanni Manghi over 4 years ago

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).

#6 Updated by Giovanni Manghi over 2 years ago

  • Regression? set to No
  • Easy fix? set to No

#7 Updated by Giovanni Manghi 7 months ago

  • Resolution set to end of life
  • Status changed from Open to Closed

Also available in: Atom PDF