Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the edit widgets do not work as expected #19048

Closed
qgib opened this issue Jun 19, 2014 · 15 comments
Closed

the edit widgets do not work as expected #19048

qgib opened this issue Jun 19, 2014 · 15 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Forms High Priority

Comments

@qgib
Copy link
Contributor

qgib commented Jun 19, 2014

Author Name: Salvatore Larosa (@slarosa)
Original Redmine Issue: 10649
Affected QGIS version: master
Redmine category:edit_widget


I tested some edit widgets like Hidden or Value Map and they are not working in current master.
If you open the sample project attached with 2.2 everything is fine.


@qgib
Copy link
Contributor Author

qgib commented Jun 19, 2014

Author Name: Salvatore Larosa (@slarosa)


  • 7471 removed demo.zip

@qgib
Copy link
Contributor Author

qgib commented Jun 19, 2014

Author Name: Salvatore Larosa (@slarosa)


  • 7472 was configured as demo.zip

@qgib
Copy link
Contributor Author

qgib commented Jun 19, 2014

Author Name: Matthias Kuhn (@m-kuhn)


The hidden fields could be improved indeed (title needs to be removed for autogenerated forms)

What's wrong with the value map?

@qgib
Copy link
Contributor Author

qgib commented Jun 19, 2014

Author Name: Matthias Kuhn (@m-kuhn)


Partially fixed in changeset "8b898b9645967a306b84b7f72ee5e5a9d1cf111e".


  • status_id was changed from Open to Closed

@qgib
Copy link
Contributor Author

qgib commented Jun 19, 2014

Author Name: Salvatore Larosa (@slarosa)


Hi Matthias, why it was closed?
Just compiled and the issue is still there :-(

Can you hide fields? is it working for you?

What's wrong with the value map?

The value map in 2.2 shows descriptions for the values (see image)
either in the attribute table or identify result:

!vmap_22.png!


  • 7476 was configured as vmap_22.png

@qgib
Copy link
Contributor Author

qgib commented Jun 19, 2014

Author Name: Matthias Kuhn (@m-kuhn)


Hi Salvatore, I was not aware that you were talking about the attribute table, from the context I thought you were talking about forms.

Anyway, it should be fixed with the last commits

@qgib
Copy link
Contributor Author

qgib commented Jun 19, 2014

Author Name: Salvatore Larosa (@slarosa)


Thanks Matthias!


  • resolution was changed from to fixed/implemented

@qgib
Copy link
Contributor Author

qgib commented Jun 20, 2014

Author Name: Giovanni Manghi (@gioman)


Salvatore Larosa wrote:

Thanks Matthias!

May be I can clarify what is going on with the Value Map.

in past QGIS releases the value map worked like many expected: the user choose by using the description and QGIS wrote the value in the table.

at some point the Value Map started to work in a different way: the user choose by the description and QGIS still wrote the value, but when opening the table in QGIS, the program always shows the description (just because the widget was active, if opening the table with another software the column was filled with the values from the map).

we had a long discussion with Jurgen, and of course he won :)

@qgib
Copy link
Contributor Author

qgib commented Jun 20, 2014

Author Name: Paolo Cavallini (@pcav)


Agreed, the previous behaviour made more sense to me.

@qgib
Copy link
Contributor Author

qgib commented Jun 20, 2014

Author Name: Matthias Kuhn (@m-kuhn)


What's the "previous behaviour"?

I think the way it works with the latest patches is the one that jef was in favour of and which I also think is the right way.

@qgib
Copy link
Contributor Author

qgib commented Jun 20, 2014

Author Name: Giovanni Manghi (@gioman)


Matthias Kuhn wrote:

What's the "previous behaviour"?

the map has two columns, description and value.

The user chooses by the description and qgis write (and shows) the value.

Now it is (was?): the user chooses by the description and QGIS still writes the value, but shows the description.

@qgib
Copy link
Contributor Author

qgib commented Jun 20, 2014

Author Name: Paolo Cavallini (@pcav)


IMHO description and value should be two different field, with two different contents. The user should select the description, and the field should be filled with the value.
E.g.:

  • the user selects the common name for an animal species, and the scientific name goes to the table
  • the user selects the descriptive name for a type of road, etc, and the corresponding code goes to the table

@qgib
Copy link
Contributor Author

qgib commented Jun 20, 2014

Author Name: Giovanni Manghi (@gioman)


  • the user selects the common name for an animal species, and the scientific name goes to the table
  • the user selects the descriptive name for a type of road, etc, and the corresponding code goes to the table

this is what always happens (before and after). The "Only" difference is that in latest qgis releases if the widget is active then in the table it always shows the animal specie/road name, when actually in the table is written the scientific name/road code.

@qgib
Copy link
Contributor Author

qgib commented Jun 20, 2014

Author Name: Matthias Kuhn (@m-kuhn)


Paolo, if I understand correctly, that's the way it works since about three hours (latest patches). I simply forgot about it before, Value Relation already worked that way.

In the QGIS UI always the description is shown. The value is only used for the backend.

@qgib
Copy link
Contributor Author

qgib commented Jun 20, 2014

Author Name: Paolo Cavallini (@pcav)


Confirmed, thanks.

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! High Priority Forms labels May 25, 2019
@qgib qgib closed this as completed May 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Forms High Priority
Projects
None yet
Development

No branches or pull requests

1 participant