Tag: formatting

Displaying numeric fields in SharePoint 2010 without commas

A common request is to display number fields in SharePoint 2010 lists without commas. For example, if you had a list of books that included PublicationYear column, it would format the values as:

  • 2,001
  • 1,998
  • 2,011

This is confusing to the viewer, as values no longer look like years.

The most frequent suggestion is to create an additional field that calculates a value based on the Number field and ignores all non-numeric parts. This is relatively straightforward, and can be accomplished entirely within the browser:

=TEXT([MyNumericData], "0")

Or, in a case where you’d like to retain two digits after the decimal:
=TEXT([MyNumericData], "0.00")

SharePoint appears to store the data in its numeric format in a another column, hidden to the browser but visible in SharePoint Designer. It’s [column name] followed by a period. For example, I created a field called MyNumericData, so the hidden field is MyNumericData. Again:

  • MyNumericData
  • MyNumericData.

Adding this to a view via SharePoint Designer is non-obvious. Here are the steps I used:

  1. Click on a data item in Design mode until you see a tab labeled xsl:value-of:
    SharePoint Designer 2010 Design Mode
  2. Right-click the item and select Edit Formula
  3. Remove the current XPath expression
  4. Add the MyNumericData. row from the fields pane
  5. Add the format-number function from the Math / Number functions
  6. Add the appropriate format pattern (e.g. ‘#’)

The appropriate format pattern depends on how you wish to display the data:

  • Display integer value:
    format-number($thisNode/@MyNumericData.,'#')
  • Always display two digits after the decimal:
    format-number($thisNode/@MyNumericData.,'0.00')
  • Display up to 2 digits after the decimal:
    format-number($thisNode/@MyNumericData.,'#.##')

If you look at the code view after making these changes, you will see that SharePoint Designer added a hefty chunk of XSL to the XsltListViewWebPart.

Is there any advantage to this method over adding a calculated field? Not as far as I can tell–but it’s interesting to note that there is more than one overly-complicated solution to what seems like a trivial problem.