The behavior is by design. The order of processing of field values is:
Repeat 1a/b until no macro or script references remain:
1a) Expand macro references to the actual value. For instance %STR% -> L"wanted text" or %DOSCMD% -> %COMSPEC% /C
1b) Evaluate any script expressions (code between single bracket chars).
2) Convert any double bracket chars to single ([[ -> [ and ]] -> ]).
So at the point that the JScript expression is evaluated, the code that is fed to the script engine is
"'L"wanted text"'.replace(/L"([[^"]]+?)"/, '$1')"
The reason for processing in this order is to support nested script expressions and macros (script expressions and macros can expand to other scripts expressions and/or macros ad infinitum).
A couple alternatives:
1) Move the .replace code into a script function in Project or Global scripts and call it from the script expression.
2) Use a Run Script step instead of a Set Macro step (brackets aren't special in a Run Script step since the code field is already treated as script):
Application.Macros(vbldMacroTemporary).Add("Str", '%STR%'.replace(/L"([^"]+?)"/, '$1'));
|