> > I would like to see some description of the effect of ReorderField(). I > assume iOldFieldPos and iNewFieldPos have to both be existing fields, and > that intermediate fields will be shuffled along as needed to satisfy the > request - is that right?
Yes, exactly. iOldFieldPos and iNewFieldPos must be in [0, GetFieldCount()-1] If you have initially 5 fields "0", "1", "2", "3","4" : * ReorderField(1,3) --> "0", "2", "3", "1", "4" * ReorderField(0,4) --> "1", "2", "3", "4", "0" * ReorderField(4,0) --> "4", "0", "1", "2", "3" > > I am somewhat wondering if it would be better to provide a mechanism > to reorder all columns in one request. Yes, that could be a possibility. The use case I was thinking initially was a user dragging the header of a column in a table to move it at a new position. But that could be done through a global reordering method, OGRLayer::ReorderFields(int* panNewPos), panNewPos being a permutation of [0, GetFieldCount()-1]. ReorderFields() would behave such, for each field that was initially at position i, its new position would be panNewPos[i]. I believe that the implementation in shapelib would be doable, and perhaps even a bit more straightforward than the one of ReorderField() where one must be careful to move things in the right order depending on if iOldFieldPos < iNewFieldPos or not. I'll update the RFC, patch and test with that solution. > > Otherwise I am satisfied with the suggested approach. > > Best regards, _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
