Hi all. I guess this is to 'everybody'. I capitulate. Although, I still have to wonder if this is not bad design. I can't control everything I use. If I use someone else's DLL for example where I may not know the actual parameter names, might the same thing happen? This is especially true in parameter calls. A parameter sits there saying "Please send me a value to work with". Then when I send it that value, it says, "Just kidding. not interested."

In terms of a normal variable that gets its value from 'wherever', the issue is cleaner, but with regard to a parameter that is supposed to get its value directly from the command line I use to call it, I still have some trouble seeing this as good design.

Anyway, in the final analysis, you are all correct. Where there is ambiguity, it must be up to the programmer to recognize it and adjust accordingly.

Mea Culpa.

Alan

>The core issue here is ambiguity. Situations like this come up all the time in programming. Let's take the case of the use of "i" in for loops. If I don't declare the scope of "i" and use it in a for loop then I make a call inside that loop to another function that also uses "i" in a for loop it would be nice if the "i" in calling function didn't get updated with the value of "i" in the called function. But alas it doesn't work like that. Ambiguous situations like the one I described and the one you encountered happen all the time. That is why we use tools like declaring the scope of variables before we use them and in your case, using variable naming convetions.
>
>If you have one naming convention for field names and another for variables you won't run into situations like the one you describe. It looks like you were using the first letter of the field name to denote what data type it was as in "cType". Where you went wrong was you used the same convention for your parameters. Here are some rules I try to follow.
>
>l = local
>g = global
>v = parameter
>c = character
>n = numeric
>a = array
>
>a typical parameter statement would look like:
>LPARAMETERS vcLine, vcPos, vcType, vnLen, vnDec, vcDelim
>
>Then I might have some local vars declared like this:
>LOCAL lcString, lnNum
>
>It really comes down to good coding practices. I don't want to offend you but I don't see your situation as problem with VFP, I see it as a problem with your coding practices.
>
>
>
>>Seriously?
>>
>>I can't see how anything should take precedence over a parameter deliberately sent to a function. If I call a function sending it a series arguments, I should be able to reasonably expect the function not to arbitrarily decide to chuck my argument into the trash and use something it likes better. How could I trust any function to use the arguments I send it?
>>
>>If this is one of those 'by design' situations, I think it is terrible design. Such a design would mean having to design field names taking into account parameter names in every function that might be used in the project (some of which might not even be my own). Or vice-versa. That would be horrible.
>>
>>Alan
>>
>>>Is it really a bug? I've always been able to access the values in a field by
>>just using the field name if the field name matched one in the current selected table. In your case where you have a local var and a field name that have the same name it looks like the field name takes presidence. I don't see this as a bug.
>>>
>>>>I had a very strange situation happen to me the other day, and while I've corrected it, I'm wondering if anyone else has run into teh same thing. It appears to be a bug in VFP - I'm using VFP6 with SP5.
>>>>
>>>>I have a function that I've been using for a long time that pulls information out of a string by position between delimiters. The signature looks like this:
>>>>
>>>>* Function to return a value from a text string by position
>>>>FUNCTION fGetVal
>>>>LPARAMETERS cLine, cPos, cType, nLen, nDec, cDelim
>>>>* cLine - the line that contains the required info
>>>>* cPos - the position number in the line of the data required
>>>>* cType - the type that the data will have to match
>>>>* nLen - number of characters to bring back - ignored if not type 'C'
>>>>* nDec - the number of decimals, defaults to 0
>>>>* cDelim - character that separates the fields - defaults to a comma
>>>>
>>>>This function has been working fine for a long time, but suddenly in one project, it didn't. It was returning an empty string when it should not have been.
>>>>
>>>>When I stepped through it in the debugger I discovered that even though I was sending it the correct arguments, it was taking the 'cType' parameter value from a field called cType in the view that was current at the time.
>>>>
>>>>I was doing lcVal = Alltrim(fGetVal(txtString, '5', 'C', 100)) - nDec and cDelim default if not sent. The 1st 4 arguments are required.
>>>>
>>>>In the debugger, the value of the Parameter 'cType' was 'Sample ', which was the content of the cType field in the view in the current workarea.
>>>>
>>>>The fix was simple - changing the parameter name or changing the field name worked equally well. I opted for changing the field name in this case.
>>>>
>>>>Has anyone else run into this scary little bug?
>>>>
>>>>Alan