Conditional Fields With String Functions, Office 2010

[thpanos]

Hi,
I am trying to insert string functions in the TrueText or FalseText of a conditional field.
I did not succeed to find any documentation on this topic.

Example:

{IF {docproperty customprop1}<>"" "txt1" "txt2"}

It works OK, returning txt1 or txt2.

What if I want to replace "txt1" with "txt1"+left({docproperty customprop2}, 2)? (+ or & or ...)?


or replace "txt1" with MID("txt1", 1, 2)

The same with MID, INSTR, RIGHT functions

Unfortunately it seems that we cannot use string functions on the TrueText or FalseText of the condition
or manipulate custom property values with string functions.

Any ideas?

[macropod]

Hi thpanos,

There are no MID, LEFT, RIGHT, etc field functions, so the ability to manipulate them via field coding is limited. If your DOCPROPERTY field returns a number, though, Word's field math functions can be used to return any portion. Dates & times, too, can be worked with, though doing so is fairly complicated.

[thpanos]

Hi Paul,
thank you for the answer.

Unfortunately my target is a string produced from access via automation.
so, I think I must process it in access before entering in word

Regards,

Theodore Panos

[macropod]

Hi Theodore,

Since you're populating document properties with the data, whatever code you're no using could be used to populate another with the required substring, which another DOCPROPERTY field could reference.

[thpanos]

Hi Paul,
The problem is that these custom fields reside in a building block and their values are derived indirectly from access.

I explain:
Access code goes to a (word) bookmark, inserts some invisible custom fields ({set ...}), the above building block (with custom fields inside {ref ...}) is inserted to the selection point, and, the (building block) custom fields are populated from the invisible custom fields.

String manipulation of custom fields would make my life easier.

Theodore Panos

[macropod]

Hi Theodore ,

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}).

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.

[thpanos]

Hi Paul,
thank you for your time, your knowledge is valuable.

I agree with you,
of course the above is more painful than processing it, inside access, even if the "ecological niche" of the process must reside inside word, as this processing belongs to the word document.

The problem described, above is part of a repeating process via which a repeating structure (building block) is inserted in the doc as a "variable rows" repeating scenario that derives from a one-to-many relationship in ms access.

1. The "one-to-many" query is extracted from ms access and the selection point goto a word bookmark.
2. Invisible custom fields are inserted ({set ...}).
3. A building block is inserted "many" times transforming itself according to internal custom fields {if ...}
4. The building block is selected and custom fields are unlinked inside it, and, loop...

The same custom fields can be reinserted and reused according to the "next row" logic.

The scenario is already complicated without the proposed conditions, so, I will process it in MS access during the query

Best Regards

Theodore Panos