No, then again, I not as a rule needed to do this.
I did a good multi-year stint working in FoxPro...the "last" dos version
make (2, or version 2.6..can't remember right now).
Anyway, in FoxPro, we had a feature in which "code", or expressions could
represent values. It was certainly a very cool and handy feature.
On the other hand, I been writing FAR MORE code intensive and FAR MORE
complex application in ms-access then I ever did in that old version of
FoxPro.
The amazing part is that I NOT missed this ability ms-access to "substitute"
string code.
What this means is that you might wan tot suggest what exactly you are
trying to accomplish instead of trying to build re-time code that modifies
it self.
The #1 REASON WHY I not missed "macro" substitution feature of FoxPro in
ms-access is because virtually EVERYTHING in ms-access is a collection. And,
all collections CAN BE resolved with strings (expressions) in ms-access at
runtime.
further, since tables are collections in ms-access, in place of storing this
value in a variable, why not store it in a table? (or a custom collection).
I can't recommend any design in ms-access now that needs you to resolve
variable names at runtime, as we simply don't need to do this anyway....
If you favourite a table defined, and use a reocrdset, then the fields
(values) are simply a collection.
strWhatFieldName = "Company"
Msgbox "the comapnaye name is " & rstCustomers(strWhatFieldName)
the above msg box would display the company name field. so, this is why I
mentioned that I not missed this "substitution" feature that FoxPro had, and
if you design your software with the above knowledge in mind, you not need
to resolve to variables at runtime at all......
I think with a "minor" change in your design, you can avoid all of your
problems....