Let me clarify, now that I'm back at work and can see the "problem".

Here's the code sample that I tested with:
code:
 
                 ; undefined (pass 1)
$OTHER=""        ; init NULL (pass 2)
$OTHER="other"   ; defined (pass 3)

@KIX

? "This and than and $OTHER stuff" 
? "This and than and " + $OTHER + " stuff" ?
The first time I ran this script, there were NO "$OTHER=" definitions, so $OTHER was undefined.

The second time, I added the definition to Null, whild the third time I changed the definition to contain text.

Here's the output from my 2K workstation:
code:
 
P1GAB01 - D:\Development>x
4.20 Release Candidate 3
This and than and $OTHER stuff
This and than and  stuff

P1GAB01 - D:\Development>x
4.20 Release Candidate 3
This and than and  stuff
This and than and  stuff

P1GAB01 - D:\Development>x
4.20 Release Candidate 3
This and than and other stuff
This and than and other stuff
Again, what my original reference was is that an undefined string value is treated differently inside and outside of quotes. I would EXPECT that an undeclared string inside of quotes return NULL, as it does outside of quotes (and in other scripting environments). Basically - unless the engine sees "$$varname", it would output the value of "$varname" and not treat it as a literal.

Anyway, it was posted here to see if we could get the behaviour changed in a future release.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D