ThinkGeo.com    |     Documentation    |     Premium Support

Label numeric format error in development builds?

#1

I apply a text style for numeric data that has the .NumericFormat property set to "{0:F0}".     In 5.5.33, I get a map that displays values as expected...   values of 2, 4, 5, etc are displayed as "2", "4", and "5".   But in 5.5.160, these same values are displayed as "{0:F2}", "{0:F4}", and "{0:F5}".    Has something changed with the way the .NumericFormat property works?   Or is this a bug?


Here is the 5.5.33 output



Here is the 5.5.160 output.  Note that the number behind the F is the value of the feature.




#2

Hello Ted, 
  
 Thanks for your post, could you please post some code I can have a check? 
  
 Regards, 
  
 Gary

#3

No. That will not be easy. But if you have any numeric layer, create a text style label for it to display a feature value such as Population, area, objectID, whatever. Set the TextStyle.NumericFormat = "{0:F0}". You will see the label printed as this format, with the last zero replaced by the text value, as shown in the second illustration. 



Today, I have learned that if you set the TextStyle.NumericFormat = "{0:F2}", you will see the leading zero replaced, creating a label of "{4:F2}" for the upper left label. 



This is leading me to believe you have done something with the NumericFormat to allow multiple feature values to be embedded within a single text string, or something. Has the use of NumericFormat changed since the initial 5.5.0 release? 

 



#4

This is the help for NumericFormat on the Wiki.    If  "{0:F2}" is not valid, can you tell me what the syntax of this has changed to? 
  
 NumericFormat  
  
 This property gets and sets the format that will be applied to the text which can be parsed to double type. 
   
 Remarks  
  
 With this property, you can apply formats to the text that is retrieved from the feature. 


#5

Hi Ted,


I think this might be a result of some changes made in 5.5.75.0 to resolve an issue with IsoLine labeling in this post: gis.thinkgeo.com/Support/Dis...fault.aspx


I found in my sample that if I utilzed a Custom Numeric Format found on the following MSDN link that the formatting behaved properly: 

msdn.microsoft.com/en-us/library/0c899ak8.aspx


 


Here is some sample code used I used to test:



worldLayer.ZoomLevelSet.ZoomLevel01.DefaultAreaStyle = AreaStyles.CreateSimpleAreaStyle(GeoColor.SimpleColors.Transparent, GeoColor.FromArgb(100, GeoColor.SimpleColors.Green));
            TextStyle countryTextStyle = new TextStyle("POP_CNTRY", new GeoFont("Arial",10), new GeoSolidBrush(GeoColor.StandardColors.Black));            
            //Standard Numeric Format Strings
            //countryTextStyle.NumericFormat = "{0:F0}";
            //countryTextStyle.NumericFormat = "{0:D6}";
            //Custom Numeric Format Strings
            //countryTextStyle.NumericFormat = "000.000";
            //countryTextStyle.NumericFormat = "###";            
            worldLayer.ZoomLevelSet.ZoomLevel01.DefaultTextStyle = countryTextStyle;
            worldLayer.ZoomLevelSet.ZoomLevel01.ApplyUntilZoomLevel = ApplyUntilZoomLevel.Level20;

Here is the result of using a Custom Format:

CustomNumericFormat.png640×511 75.8 KB


This would seem to be a bug as I would not expect the Standard Numeric Formatting support to be removed.

This will be created as an Internal Ticket for futher review but for now you might setup a Custom Numeric Format that matches your needs.



#6

Thanks.  I’ll give it a whirl.

#7

Hello Ted, 
  
 You are welcome, please let us know if you still meet the problem. 
  
 Regards, 
  
 Gary

#8

I have confirmed that I can use "F2" instead of "{0:F2}" and it works. I've modified my code. But I agree with Ryan... something changed on this that broke the original behavior.



#9

Hello Ted, 
  
 I’m glad it’s working, we will research this and see if we can change it back. 
  
 Please don’t hesitate to let us know your problems. 
  
 Regards, 
  
 Gary

#10

Ted, 
  
 We should have make it the current way at the beginning as that is the real format strings while "{0}" is just the parameter index. I am very sorry for the inconvenience that it broke the original behavior. 
  
 Thanks, 
  
 Ben