Looks like VFB may come back for real this time < s >

Jim N

>>I have four suggestions. If I'm being redundant or even repeating
>>something over and over again, my appologies :-)
>>
>>1) a STATIC declaration which would be similar to the C construct
>>allowing a variable's value to persist between execution iterations,
>>but allow the variable to be scoped as well. Such a declaration
>>might also allow scoping so that one could have a LOCAL STATIC or
>>a PRIVATE STATIC variable (obviously a PUBLIC STATIC wouldn't make much
>>sense). STATIC by itself could default to either (as you choose).
>
>I don't see many cases were I would use this feature, but I agree that it should be added.
>
>>2) The ability to assign an initial value in a declaration.
>>e.g:
>>LOCAL lnCounter = 0
>>PRIVATE STATIC lcOutString = ""
>
>Agree
>
>>3) An OPTION EXPLICIT, similar to VB. I think this would be invaluable
>>in aiding debugging and helping to create more stable applications.
>>Making it an option wouold allow compatibility with existing code bases
>>as well as enforcing shop standards where pre-declaration is required.
>
>I definitly want to have this feature.
>
>>4) Finally, VFP now initializes empty parameters to .F. This makes
>>checking for non-passed parameters a little more difficult than it
>>could be. Offering something like:
>>SET NULLPARM TO
>> -or-
>>SET EMPTYPARM TO
>
>Agree.
>
>>Named parameters would be nice too, but I suspect that it would add a bit of overhead to the parsing routines that would, I'm sure not be welcomed in the VFP community :-)
>
>But it could be easier to cut&paste VB samples in our code. So I think that it's a good suggestion