How can we improve Project?

Enterprise Custom Field Improvements

Support for enterprise custom fields in the Project Client COM object model is minimal and has not changed much since 2000. Field access is not type-safe because everything with GetField and SetField methods is about strings and their input cell representation according to current Project configuration settings regarding date and duration formats as well as cost. Actually the value that is returned from GetField varies heavily depending on the options on how to represent the type that is used in the field. Reading enterprise custom flag fields is language-dependent (it's "Yes" or "No" or whatever the current language expressions for True and False are) which requires a lot of parsing and drops performance.
The actual data types can however be used when fields are written so that part is type aware so I see more need in support for reading the fields. While GetField always returns a string, how about a GetFieldValue method that returns a variant with the *actual* value that is behind the field I am reading? Not the formatted one as it is shown in the respective input cell. The output could be a String type for reading text fields, but should just as well be DateTime for date fields, an Integer (minutes) for work and duration fields, a Float or Currency type for cost and number fields, and a Boolean for flag fields. That would remove so much effort from all the customizing work that I am doing all day. And Project has the properly-typed values at hand all the time. I would no longer have to torture it to parse back strings that contain a date in the format that Project currently renders into date fields, just to get the value as a DateTime type.
By the way, project assignments have as good as no support at all for enterprise custom fields because the Assignment object does not expose any GetField or SetField methods, even though it is actually possible to write the fields in the usage views of the Project client's UI. So customers keep asking me how it is possible that they can freely edit and see custom fields on assignments whereas I cannot even see them in the code, let alone modify them.
The only way to access enterprise custom fields at all on assignments presumes their names do not contain any spaces. Then I can access them like the built-in assignment properties because Project mirrors the custom fields into the Assignment type interface through some obscure IDispatch hack. But basically I don't want to do that because field names are then part of the code, no longer part of the configuration, and the code will stop working the moment one of the fields does not exist or was renamed. Furthermore, many customers have a field naming convention that I would have to break just to make the fields accessible to the code. And most of them do not like FieldNamesWithNoSpacesInThem or Field_Names_Separated_by_Underscores. It's just not what the majority of users wants.
GetField/SetField (and of course GetFieldValue) methods for the Assignment type would solve this for good.

26 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Johannes Franke shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    2 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...

      Feedback and Knowledge Base