Bug report #12625

Difficult to set value in drop down list in table column

Added by Patrick Dunford almost 9 years ago. Updated about 5 years ago.

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

Description

When I select a feature on the map and then I open the attribute table for the layer and change the view to Show Selected Features.
I have a column called Type. I try to change the value of Type which is a Value Map so it shows a drop down list.
And then I press Save button.
Then the value in Type column I just changed will change itself back to the previous value
And then I have to change Type again and save again.

And then I change the selection to work with another feature.
Then I select the feature I was working with before.
And in Type column it still shows the original value before I changed it even though the map style reflects the changed value. (The maps use rule based styles with the Type column being the column that is used in the style rules)
And this is very annoying.

Untitled_1.avi (1.12 MB) Patrick Dunford, 2015-11-27 09:49 PM


Related issues

Duplicated by QGIS Application - Bug report #12387: Value map fields are always treated as text Closed 2015-03-17

History

#1 Updated by Giovanni Manghi almost 9 years ago

  • Category set to Edit widget
  • Status changed from Open to Feedback

I cannot confirm on QGIS master (please test it). This bug sounds similar to one that now I cannot find and that was about the value map widget not writing the right value after having reordered one of the columns. But this issue was already fixed.

#2 Updated by Patrick Dunford almost 9 years ago

I'm currently using 2.5

#3 Updated by Giovanni Manghi almost 9 years ago

  • Status changed from Feedback to Closed
  • Resolution set to invalid

Patrick Dunford wrote:

I'm currently using 2.5

Use a more recent version. In 2.8.1 this is fixed. Please reopen if necessary.

#4 Updated by Patrick Dunford almost 9 years ago

  • Status changed from Closed to Reopened

This is still observed in 2.9.0

#5 Updated by Giovanni Manghi almost 9 years ago

  • Resolution deleted (invalid)
  • Status changed from Reopened to Feedback

Patrick Dunford wrote:

This is still observed in 2.9.0

could please make and attach a screencast that shows the issue? thanks.

#6 Updated by Jürgen Fischer almost 9 years ago

  • Resolution set to not reproducable
  • Status changed from Feedback to Closed

not reproducable on master. closing for the lack of feedback.

#7 Updated by Patrick Dunford over 8 years ago

Here is a screen capture showng the problem
On the screen we have the two tables opened as attributes, the source table on the left and the destnation table on the right.
00:00:05 select a record of the source table
00:00:26 A Cut of the selected record was performed
00:00:36 a Paste to the new table was performed and we scroll to the bottom to see the new table. Note that even though the tables have identical attributes the record was pasted with all fields values cleared.
00:00:39 The value in the Type column was changed from null into one of the values in the drop down list using the mouse.
00:00:44 The Save button was used to save the new record to the table.
00:00:45 We scroll to the bottom to find the new record with the type field value we just entered, has been cleared.
After settng the type again and saving again it gets remembered this time.

QGIS version
2.10.1-Pisa
QGIS code revision
d20c5b7
Compiled against Qt
4.8.5
Running against Qt
4.8.5
Compiled against GDAL/OGR
1.11.2
Running against GDAL/OGR
1.11.3
Compiled against GEOS
3.4.2-CAPI-1.8.2
Running against GEOS
3.5.0-CAPI-1.9.0 r4084
PostgreSQL Client Version
9.2.4
SpatiaLite Version
4.1.1
QWT Version
5.2.3
PROJ.4 Version
480
QScintilla2 Version
2.7.2

Windows 10 x64

#8 Updated by Giovanni Manghi almost 7 years ago

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

#9 Updated by Giovanni Manghi about 5 years ago

  • Resolution changed from not reproducable to end of life
  • Status changed from Reopened to Closed

Also available in: Atom PDF