Yes, I figured you were refering to those cases.

Actually, this brings up an interesting question for VP7 which will support strong typing at design time: Will the compiler catch it?

Seems like the issue is FoxPro's foregiving ability to be able to create memvars without being preceeded with LOCAL, PUBLIC, PRIVATE which, theoretically, could be trapped as a typo be the compiler.

But again, this would affect macro substitution:

LOCAL lcSomeProperty

lcSomeProperty = [Value]

IF PEMSTATUS(This.Parent, lcSomeProperty, 5)
   This.Parent.&lcSomeProperty = [Hello World!]
ENDIF

While this is far from being a good example, you get the point.

>For example:
>
>procedure whatever
>
>private l_dorfus
>
>l_drofus = 12 && typo, but another memory variable is created
>l_dungus = u_get( "US" )
>
>return
>
>procedure u_get
>parameter l_country, l_zip
>
>return l_country+l_zip
>
>
>Neither the typo nor the parameter mismatch is caught in the compiler
>
>
>
>>What are you talking about?
>>
>>VFP catches those errors when you try to close the method editor. If you are referring to references created in a method, then yes, you are correct.
>>
>>However, the advantage of not having a stricter compiler is the benefit of having macro expansion - a benefit which far outweighs the type of compiler you are talking about.
>>
>>>One disadvantage of using Foxpro versus a stricter compiler is you can have errors that are typos, etc., that Foxpro doesn't catch that a compiler in a language with stricter typing will catch.
>>>
>>>Is there a third party tool out there for FoxPro that can do some of this type of checking?
>>>
>>>Bruce Strom