View Single Post
  #2  
Old 12-05-2005, 08:56 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,003
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'));
Reply With Quote