Hi Theodore ,
Quote:
|
The problem is that these custom fields reside in a building block and their values are derived indirectly from access
|
That may be so but, in your first post, you referred to "{docproperty customprop1}" and "{docproperty customprop2}". These are custom document properties (not custom fields in a building block) and you can see them if you go to File|Properties|Advanced>Custom. Whatever process populates these custom document properties should be able to populate another one with whatever sub-strings you need. Your building blocks should then be able to reference the new custom document properties in the same way (eg {docproperty customprop3}).
Quote:
|
String manipulation of custom fields would make my life easier
|
Whilst I agree the ability to do some string manipulation would make like easier, your options there are extremely limited.
FWIW, although you can't extract the first two characters via a LEFT function, you could use a series of fields to find out what they are. For example, you could retrieve them via field coding like:
{SET Str {docproperty customprop2}}
{IF{REF Str} = "1*" "1"}{IF{REF Str} = "2*" "2"} ... {IF{REF Str} = "A*" "A"}{IF{REF Str} = "B*" "B"} ... {IF{REF Str} = "a*" "a"}{IF{REF Str} = "b*" "b"} etc.
for the first character, and:
{IF{REF Str} = "?1*" "1"}{IF{REF Str} = "?2*" "2"} ... {IF{REF Str} = "?A*" "A"}{IF{REF Str} = "?B*" "B"} ... {IF{REF Str} = "?a*" "a"}{IF{REF Str} = "?b*" "b"} etc.
for the second.
If you have the possibility of any letter or number, that could mean having to work with 62 fields per character - 124 in all, though fewer fields are required if some characters (eg lower-case letters) can be ruled out.