none
losing leading or trailing blanks in text fields RRS feed

  • Question

  • We often use leading or trailing blanks in our custom text fields.  This is useful when you want to deconflict the text for two neigboring milestones.  We have found that you can tune your schedule to look just perfect, but if another user looks at the schedule from the Server (V2010-SP1), the leading/trailing blanks are not applied.  We have since concluded that the blanks are not saving to the Server from the cache.  Yes, we applied the hotfix that deals with cache issues for the custom flags.  Our current work-around is to use a period to bound the leading/trailing blanks.  I have been doing this since version 3.0 in 1994 and this is the first time we have ever encountered this issue.  Suggestions, anyone?
    • Moved by Mike GlenModerator Tuesday, May 15, 2012 11:18 AM More appropriate forum (From:Project Standard and Professional General Questions and Answers)
    Tuesday, May 15, 2012 11:08 AM

Answers

  • The following has been employed as a successful work-around:

    Consider text below the milestone/task that we want to shift left or right.  The user would put his/her desired text into an enterprise field called "#Bottom".  The user can then shift this text either left or right using a numeric value of spaces in the entprise field called "#Bottom Spaces".  A negative number would be a shift left and a positive number would be a shift right.  Create another enteprise field titled "#Bottom Text - Shifted".  Use the following formula (for summary's and rollups as well):

    IIf([#Bottom Spaces]>0,Space([#Bottom Spaces])+[#Bottom],[#Bottom]+Space(ABS([#Bottom Spaces])))

    Address the field "Bottom Text - Shifted" in the desired bottom fields in Format==>BarStyles.

    We wish that we didn't have to resort to this, but it works.

    Monday, February 4, 2013 5:21 PM
  • UPDATE!  Our Server that is operating in BCM had a file that still had leading / trailing blanks when opened with a 2007 client.  Clearing the cache did not seem to make a difference.  We then opened this same file with a 2010 client and no surprise, the blanks were gone.  We closed that file without saving from the 2010 client.  We then immediatly reopened the file with a 2007 client and now the blanks are gone!  Additional attempts to get the Server to remember leading/trailing blanks are now being re-buffed. 

    Conclusion: touching a file with a 2010 client, even if you don't save the file, changes some properties of the file which allows leading / trailing blanks in text fields to be saved to a 2010 Server.  The ability to save leading / trailing blanks in a text field to a 2010 Server is retained as long the file is only touched by 2007 clients.

    Tuesday, October 15, 2013 7:21 PM

All replies

  • Using blanks in custom field names has never been a best practice. Project Server will trim them, so I think you answered your own question.

    Gary Chefetz, MCITP, MCP, MVP msProjectExperts
    Project and Project ServerFAQs
    Project Server Help BLOG

    Tuesday, June 26, 2012 10:07 AM
    Moderator
  • Gary - look at the example that I provided on this post:

    http://social.technet.microsoft.com/Forums/en-US/projectprofessional2010general/thread/beb93a48-4ea5-4dc3-a93b-07dbac229cd4

    I had to buffer the text with a leading or trailing period to get in the buffer blanks.  It was not until V2010 that I had to do this.  Something changed with this version.

    Tuesday, June 26, 2012 11:33 AM
  • Gary - my one hope here is that somebody from Microsoft would take notice that they changed something that took away a capability that we have been using for 17 years.

    One of our key strategies is to generate presentation-quality schedules using the same schedule data that we are using for analysis.  We distrust disjoint systems where the presentation schedules are kept in one tool (like Fastrac or Visio) and the analysis data is kept in another tool.  It has been proven over and over again that when put in that situation we burn far too much energy polishing the presentation schedules and the schedule data falls out of date.  Once that happens we enter a death spiral which requires more and more people to maintain synchronization of the schedules dates between all these disjoint "drawn" schedules. 

    Buffering the text underneath a milestone or task with padded blanks is a strategy that we have successfully used since 1995 in the creation of presentation-quality gantts.  V2010 just took that away from us.

    Thursday, June 28, 2012 11:05 AM
  • The following has been employed as a successful work-around:

    Consider text below the milestone/task that we want to shift left or right.  The user would put his/her desired text into an enterprise field called "#Bottom".  The user can then shift this text either left or right using a numeric value of spaces in the entprise field called "#Bottom Spaces".  A negative number would be a shift left and a positive number would be a shift right.  Create another enteprise field titled "#Bottom Text - Shifted".  Use the following formula (for summary's and rollups as well):

    IIf([#Bottom Spaces]>0,Space([#Bottom Spaces])+[#Bottom],[#Bottom]+Space(ABS([#Bottom Spaces])))

    Address the field "Bottom Text - Shifted" in the desired bottom fields in Format==>BarStyles.

    We wish that we didn't have to resort to this, but it works.

    Monday, February 4, 2013 5:21 PM
  • As an update, we have just learned at Project Server while operating in Backward Compatibility Mode (BCM) will also not allow the synchronization to the Server any leading or trailing blanks in text fields, even if you are using a 2007 client.  Thus, this is not an issue with the client software, but rather the Server, as we suspected.
    Thursday, September 12, 2013 10:41 AM
  • UPDATE!  Our Server that is operating in BCM had a file that still had leading / trailing blanks when opened with a 2007 client.  Clearing the cache did not seem to make a difference.  We then opened this same file with a 2010 client and no surprise, the blanks were gone.  We closed that file without saving from the 2010 client.  We then immediatly reopened the file with a 2007 client and now the blanks are gone!  Additional attempts to get the Server to remember leading/trailing blanks are now being re-buffed. 

    Conclusion: touching a file with a 2010 client, even if you don't save the file, changes some properties of the file which allows leading / trailing blanks in text fields to be saved to a 2010 Server.  The ability to save leading / trailing blanks in a text field to a 2010 Server is retained as long the file is only touched by 2007 clients.

    Tuesday, October 15, 2013 7:21 PM