Some data structures exposed in the ArcGIS Maps SDK for Qt use underlying data structures implemented with case-insensitive string keys. Most often Geodatabases.
How these are exposed to users of the ArcGIS Maps SDK for Qt will vary, but users should be aware of the differences in behavior.
Working with these types in the ArcGIS Maps SDK for QtWhen these types are exposed through a QVariantMap or similar, the keys will be case-sensitive because that is how QString behaves with comparisons. In these cases, the underlying data structure is still case-insensitive.
When working with AttributeListModel (for example), APIs like 'containsAttribute' may behave unexpectedly where any variation of the case of a contained key will return true.
AttributeListModel* attributes = graphic->attributes();
attributes->insertAttribute(QString{"key"}, QVariant{"value"});
bool contains = attributes->containsAttribute("KEY"); // true
contains = attributes->containsAttribute("key"); // true
contains = attributes->containsAttribute("KeY"); // true
// and so on and so forth
Similar differences will be noticed in other AttributeListModel APIs.
Passing in attributes using QString-keyed mapsIn some cases, like FeatureTable::createFeature for example, you pass in a QVariantMap of attributes. Be mindful of this difference because a QVariantMap holds case-sensitive keys, like so:
QVariantMap attributes;
attributes.insert(QString{"key"}, QVariant{"value"});
attributes.insert(QString{"KEY"}, QVariant{"another value"});
// this may lead to unexpected results. In some cases it will be last-in-wins behavior, but
// this is considered undefined behavior and the end result will be that you will not have both keys
// in the Feature's attributes.
Feature* feature = featureTable->createFeature(attributes, geometry, this);
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4