<div dir="ltr"><div><div class="gmail_extra"><div><div><div><div>Hi,<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">martin Dobias wrote:<br></blockquote>

<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<div> </div></blockquote></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">The source of the problem is that before, it was possible to have
<br>"holes" in attribute field indices: e.g. three attributes with indices
<br>0,2,3. Whether such holes appeared depended on the provider being
<br>used. The support for holes has been removed for performance and
<br>simplicity - many developers were not even aware of this thing.
<br><br>As a quick fix I think you'll need to update your project file. The
<br>proper fix should change writing of attributes as names in
<br>data-defined properties (for new labeling).<br></blockquote><br></div><div>Ok, I've looked into fixing this (and have a couple of ideas), but need a clarification first:<br><br></div><div>Is mFields[i].originIndex (where mFields is a QgsFields vector) the same index used for the keys in QgsFieldMap?<br>
<br></div><div>In other words, will this new method, QgsFields::toQgsFieldMap(), function correctly [0]? If so, I can use it to attempt to auto-convert QgsFieldMap-index-based data defined properties over to field-name-based properties, without having think about reintroducing any QgsFieldMap functionality at the provider level.<br>
<br></div><div>If adding that method is a reasonable approach, do I need to filter the added fields in any way (e.g. by FieldOrigin)?<br></div></div></div><br>[0] <a href="http://drive.dakotacarto.com/qgis/qgsfields-qgsfieldmap_patch.diff">http://drive.dakotacarto.com/qgis/qgsfields-qgsfieldmap_patch.diff</a><br>
<br clear="all">

<div>Regards,<br></div><div><br>Larry<br><br></div></div></div></div>