>Good Morning Dragan,
>
>I have found that ME can be avoided in nearly all data driven cases by using the following:
>
>loObj = eval('thisobj.'+lcProperty)
>store eval(lcValue) to ( 'AliasName.'+lcFldName)
>store eval( 'AliasName.'+lcFldName) to lcValue
>DEFINE bar cntbar('SomeMenuPopUp') + 1 of (SomeMenuPopup) prompt ;
> ( LCPROMPT ) style (iif(llSETMARK,'B','N'))
> set mark of bar cntbar('SomeMenuPopUp') of clear SETMARK
>
>The places I have found where evel will not work is :
>
>INDEX ON &lcvar TAG(lcvar)
>SET TALK &lconoff
>
>and some SQL constructs.

I had to find that myself - thanks for the comprehensive list. My point was that Eval is just a shorter version of macro expansion, namely it's just an expression evaluator, not capable of issuing a command as ME is doing. But it equally relies on the existence of all the variable and object names. In a compiled environment, variable names don't exist, they are replaced with pointers to storage locations or pointers to descriptors (in cases where storage is dynamic), unless the names are published to the outer world - but then they are available to the outer world only, and they are the method names, entry points etc, not variables. Even eval() would disappear in a strictly compiled environment.

I VFP, as it is, we can always avoid macro expansion by generating a .prg and compiling it on the fly - but then compilation on the fly is unthinkable in a compiled environment.