Bug report #4607

Do not show not pertinent fields in the "data defined settings" of the labelling tool

Added by Giovanni Manghi almost 8 years ago. Updated over 5 years ago.

Status:Closed
Priority:Normal
Assignee:Larry Shaffer
Category:Labelling
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed
Crashes QGIS or corrupts data:No Copied to github as #:14512

Description

For example, why show non integer columns for the "rotation" field? Like this all the others should accept just text or integer fields.

History

#1 Updated by Paolo Cavallini almost 8 years ago

See also #4613

#2 Updated by Giovanni Manghi almost 8 years ago

  • Target version changed from Version 1.7.3 to Version 1.7.4

#3 Updated by Paolo Cavallini over 7 years ago

  • Crashes QGIS or corrupts data set to No
  • Target version changed from Version 1.7.4 to Version 1.8.0
  • Affected QGIS version set to master

#4 Updated by Paolo Cavallini about 7 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#5 Updated by Giovanni Manghi almost 7 years ago

  • Assignee set to Larry Shaffer

seems still an issue in master, text fields are shown for parameters that need to be just numbers.

#6 Updated by Larry Shaffer over 6 years ago

Hi Giovanni,

I have implemented this in the new QgsDataDefinedButton. However, and considering basic types, restricting options that require an Int or Double input value to only data source fields that support those types in a bit limiting.

This is because the resultant value, either from a direct feature field-mapped attribute query, or from an expression, can often be successfully converted to the appropriate type. For example, almost all results are QVariants, which means the result needs be be converted from QVariant to the expected type before it can be used.

Specifically:

double QVariant::toDouble ( bool * ok = 0 ) const

Returns the variant as a double if the variant has type() Double, QMetaType::Float, Bool, ByteArray, Int, LongLong, String, UInt, or ULongLong; otherwise returns 0.0.

int QVariant::toInt ( bool * ok = 0 ) const

Returns the variant as an int if the variant has type() Int, Bool, ByteArray, Char, Double, LongLong, String, UInt, or ULongLong; otherwise returns 0.

QString QVariant::toString () const

Returns the variant as a QString if the variant has type() String, Bool, ByteArray, Char, Date, DateTime, Double, Int, LongLong, StringList, Time, UInt, or ULongLong; otherwise returns an empty string.

So you can see that conversion to Int or Double can accept a String, and vic-versa. So there is really no need to limit the data source field type, unless you know it can not be successfully converted to what's needed. For example, if a data defined value might be the text 'Half' then limiting to only String type fields makes sense because Int and Double fields could not possibly produce such a result.

#7 Updated by Giovanni Manghi over 6 years ago

  • Status changed from Open to Feedback

Hi Larry,

thanks for the detailed explanation.

So if you think that the original issue make no sense especially after your labelling overhaul, please close this ticket.

cheers!

Larry Shaffer wrote:

Hi Giovanni,

I have implemented this in the new QgsDataDefinedButton. However, and considering basic types, restricting options that require an Int or Double input value to only data source fields that support those types in a bit limiting.

This is because the resultant value, either from a direct feature field-mapped attribute query, or from an expression, can often be successfully converted to the appropriate type. For example, almost all results are QVariants, which means the result needs be be converted from QVariant to the expected type before it can be used.

Specifically:

double QVariant::toDouble ( bool * ok = 0 ) const

Returns the variant as a double if the variant has type() Double, QMetaType::Float, Bool, ByteArray, Int, LongLong, String, UInt, or ULongLong; otherwise returns 0.0.

int QVariant::toInt ( bool * ok = 0 ) const

Returns the variant as an int if the variant has type() Int, Bool, ByteArray, Char, Double, LongLong, String, UInt, or ULongLong; otherwise returns 0.

QString QVariant::toString () const

Returns the variant as a QString if the variant has type() String, Bool, ByteArray, Char, Date, DateTime, Double, Int, LongLong, StringList, Time, UInt, or ULongLong; otherwise returns an empty string.

So you can see that conversion to Int or Double can accept a String, and vic-versa. So there is really no need to limit the data source field type, unless you know it can not be successfully converted to what's needed. For example, if a data defined value might be the text 'Half' then limiting to only String type fields makes sense because Int and Double fields could not possibly produce such a result.

#8 Updated by Larry Shaffer over 6 years ago

  • Status changed from Feedback to Resolved
  • Resolution set to fixed

Should be fixed with commit 45f374f4

Reopen if necessary

#9 Updated by Jürgen Fischer over 5 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF