>Len-
>
>>According to the FAQ that Nadya pointed to, macro substitutions are NOT compiled (tokenized), whereas name expressions are. So his statement that there is a difference when compiled is true (unless the FAQ is wrong).
>
>Macro expressions are evaluated at runtime, as are named expressions and EVAL() expressions. That wasn't the point. The point was the assertion that you can do macro expansion in VCX and then came up with a wild speculation as to why. The trouble I have with that post is that would have taken 5 minutes to see if macros _can_ be used in VCXs which they can. It was lazy. The worst kind of laziness I most despise in myself.

My only complaint was you exhibiting the same kind of laziness - telling someone they are wrong without elaborating why they are wrong (that & the tone you used).

When I read the original problem, I made the assumption (possibly wrongly) that the path used in the macro substitution was the same in both cases (class & prog) & worked in one case & not the other.

I thought your solution bypassed the problem. It was a perfectly valid solution, but didn't make any attempt to solve the real problem of why the macro substitution worked in one case but not the other, when it really should have. Regardless of spaces in the path, it should have worked in both cases or not at all (see my assumption above).

Andrew gave his theory (qualified by maybe) on why the problem existed in the first place. He was probably mistaken in putting forward a theory without the evidence to back it up, but your response got my back up. As I pointed elsewhere, you didn't correct him, just said he was wrong.

And yes, I did try it & I could not reproduce the problem of working in one place & not the other.