Please sign in to comment.
Split displayField into displayExpression and mapTipTemplate (#1973)
Previously there was the expressionField (a field name or an expression) mainly used for the feature list in the form view of the dual view. On the other hand there was the displayField which could contain either a simple field name or a complex HTML structure with embedded expressions. And to know what it was you could compare it's content with the field names, if a field name matched, you used it as a displayField (original purpose) and if not... well, you could deal with HTML if you had a use for it. The main problem is that there are two different usages for this kind of thing * plain text identifier (field or expression) * pretty, rich text feature info This commit cleans up with this. You want rich text and a lot of info: go for mapTipTemplate. You want a plain text string to identify features: go for the displayExpression.
- Loading branch information
Showing with 365 additions and 483 deletions.
- +2 −0 doc/api_break.dox
- +40 −5 python/core/qgsvectorlayer.sip
- +12 −21 src/app/qgisapp.cpp
- +10 −3 src/app/qgsidentifyresultsdialog.cpp
- +26 −69 src/app/qgsvectorlayerproperties.cpp
- +6 −8 src/app/qgsvectorlayerproperties.h
- +86 −107 src/core/qgsvectorlayer.cpp
- +47 −10 src/core/qgsvectorlayer.h
- +2 −47 src/gui/attributetable/qgsdualview.cpp
- +17 −15 src/gui/qgsmaptip.cpp
- +3 −3 src/gui/qgsmaptip.h
- +9 −2 src/server/qgsserverprojectparser.cpp
- +11 −13 src/server/qgswmsserver.cpp
- +94 −180 src/ui/qgsvectorlayerpropertiesbase.ui
Oops, something went wrong.