>Often requested implies that a preponderance of developers ask for this sort of thing. Also, in your case, what you are looking for is something that bascially does the same thing as macro-substitution.
Not necessarily. The same 10 developers could ask for it several times.
>
>The fact is, most VFP developers will tell you that macro-substitution is one of those "key" features that separates VFP from other tools. Are there some developers who would not mind dropping macro-substitution. Sure - as long as you could retain most of the functionality. In other words, they want their cake and the ability to eat it as well.
>
>Craig is incorrect in that it is often requested that Macro Substitution be dropped.
Go look at the number of developers that ask for a native VFP compiler, which would rule out macro substitution. FWIW, I'm in the "keep macro substitution camp".
>
>
>
>>>Excuse me???
>>>
>>>Often requested to drop macro substitution? Sorry, I don't beleive that for one moment. Rather, folks don't want to give up macro substitution. This issue comes up when folks want VFP to be compiled - like VB. This would mean the giving up of macro substituion. Folks usually back off when they have make this compromise.
>>>
>>>Sorry Craig, but you are flat out incorrect here.... Again, you have pulled out "facts" from think air...< s >...
>>
>>I have stated that I would be easily willing to give up macro substitution if we were given a few key things in exchange: a substitute for functions that take only literals instead of named expressions (certain SET commands), and a way to execute SQL expressions (a substitute for &lcSQL).
>>
>>I have heard several other developers echo these sentiments, and Craig has probably heard the same talk- how does that make him 'incorrect'?
Craig Berntson
MCSD, Microsoft .Net MVP, Grape City Community Influencer