QGIS » QGIS Application

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

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.

Should be fixed with commit 45f374f4

Reopen if necessary