I have a problem with generating labels based on a field in the shapefile table since moving to 5.2. This is code that was working fine beforehand.
There are a few different paths to the problem, but I attach a sample project (with data) that should show the issue. I’ve tried it with different shapefiles too (with different fields). I’ve also tried a few methods of generating the labels.
If you compile and run the attached project it will load a shapefile. If you check “Show labels” it will generate the labels and show them correctly. If you uncheck “Show labels” it will clear the labels from the map. If you keep checking and unchecking the checkbox it will work correctly - all good so far…
However if you run the project, click the “Edit labels” button then check the “Show labels” checkbox, it will again look ok, but uncheck once more and check again the labels do not show! I have found in my production software, they are usually (perhaps always but not visible) generated but either in some random offset or in a (rough) diagonal line across the screen (not seen in the attached project).
Obviously it would be great to have this working again.
I thought I’d implemented a workaround for this, but I’ve realised it does not work. It seems as though any time you call “Labels.Generate” a 2nd time it messes up as described previously.
I think I still get occasional breakage, but I made the following edits that seem to result in more predictable behavior. I’ve modified and commented the EditLabels method; look for comments starting with "// jf:". See how this behaves for you, and let me know.
Regards,
Jerry.
private void EditLabels(Shapefile shp)
{
shp.StartEditingShapes(true, null);
var fldIndex = shp.Table.FieldIndexByName["id"];
bool isEditingShapes = shp.EditingShapes;
bool isEditingTable = shp.EditingTable;
//shp.StartEditingShapes(true, null);
// jf: I commented the following line.
// StartEditingShapes has already called StartEditingTable,
// so there is no need to call it again here.
//shp.StartEditingTable();
for (int shpIndex = 0; shpIndex <= shp.NumShapes - 1; shpIndex++)
{
string tempStr = shp.CellValue[fldIndex, shpIndex].ToString();
if (tempStr.StartsWith("X"))
tempStr = tempStr.Remove(0, 1);
else
tempStr = "X" + tempStr;
shp.EditCellValue(fldIndex, shpIndex, tempStr);
}
// jf: I commented StopEditingTable and uncommented StopEditingShapes.
// Since you start editing with StartEditingShapes, you should
// stop editing with StopEditingShapes rather than StopEditingTable,
// otherwise you leave the Shapefile edits in an odd state.
//shp.StopEditingTable(true);
shp.StopEditingShapes(true, true);
//if (isEditingShapes)
// shp.StartEditingShapes(true, null);
// jf: I commented the following 2 lines.
// isEditingTable is always true, since you set this above just after
// you started editing. So it results in always starting a new edit operation.
//if (isEditingTable)
// shp.StartEditingTable();
// shp.Save();
}
Thanks very much for looking into it (realise I forgot to thank you at the time sorry!). Since you posted your comments, I’ve tried to reflect that in my own code, but it turns out that most of the things you changed, weren’t actually in my production code like that in any case. I have not been able to get things to work. I’ve been struggling for a while and none of my attempted workarounds have worked.
I presume there is a bug there somewhere, despite the fact you were able to improve the demo application behaviour - as the same code worked pre 5.2 and doesn’t now.
The StartEditingShapes and StartEditingTable seems to be a red herring as far as I can tell, as I’ve eliminated this as a possibility in my code and as I say, still get the issue.
This is quite an issue for me, so any further advice gratefully received!
@jerryfaust I’m wondering if it could be related to this:
…as one of the things I sometimes see is that the labels are arranged diagonally - which would tie in with the x and y positions both being set to “x”.
I made a (crude!) change to the code myself to fix this issue, but would prefer to use the official solution, so now we’re on a new development cycle I will switch to 5.3 and see if the issue is fixed.