Jan, having progressed a bit further into this: it a subroutine is going to
ask a user for the name of a custom task text field to operate on, with the
field being expressed as either it's base name or a custom alias, then it
appears that it must be handled this in three steps:
Step 1 - determine if the field name has been provided in the base name
(e.g. Text1), then look up the associated constant, or else
Step 2 - look for the custom "name" across the fields, then look up the
associated constant
Step 3 - and feed the resulting field constant, if found, into
GetField/SetField.
This results in what seems like a LOT (read pages) of low-level code to
perform a seemingly trivial operation. If you want to relax the user
constraints and allow for a value to be designated in a custom number field
as well as a custom text field, then it literally doubles in size because of
having to represent and deal with each element of the text, number, etc.
field set individually.
So the question at this point, as a sanity check, is: am I complicating
this unnecessarily, or does the structure of how Project field names are
expressed (no indexed access via a collector) and field constants defined
(non-linear sequences) in fact force this?
Thanks,
George
