Hi Jim
>I'd say this *IS* a bug.
Just so we don't adress different "mental sets", the following argument is primarily based on the premise:
"It is only a bug if not working according to the documented specs".
>
>I can't say that I've ever seen this particular behaviour documented. The code definitely uses "m." to preclude other oddities (like field taking precedence).
I'ld have to ask you to trust me on this, because I did some research caused by a difference in running a fpw-based app in vfp6.

In FPW there was an undocumented possibility to "unhide" the parameters called by reference if they were called by reference twice. I think I could find the relevant portions of that code in my emails, but am not sure if I have FPW repro code independant from lots of code from this old app.

This caused an error in the vfp-port, since this possibility doesn't work in vfp6 and caused me to research the *documented* way of operating since the old programmers gave statements defining the old app to be error free. I found the "hiding" in the FPW documentation, even if I don't remember the exact place and after some email exchange the old app was proclaimed to be "not errorfree". So the behaviour "hiding" code IS following published docs of that time. Main reason for *my* classification fulfilled and back then I had no budgetary problems fixing lots of other errors after that for half a year. So I trust my own recollection ofthis incident a lot <g>.

>I might expect differently with "PRIVATE" (have to think on that one) but here PUBLIC is declared.
I'ld absolutely HATE it if public and private variables would behave differently. Think about the problems if you try to program generic libraries and YOU are depending on how the variables were defined, (which would be out of the hand of the developer designing the generic routines but decided by the developer using the generic routines!) and you'll probably agree <g>.

Also, I personally think it is vfp's grat strength's to run old code with only minimal changes / corrections. Others may disagree, but I can refactor old code far faster than get new specs clearly defined from my customers - but at least part of that is a personal "knack".

>All that said, I do get the same behaviour using VFP8 SP1 (I do not have VFP9 installed) so I quite possibly did miss/forget some prior words on the subject.

Try going back to the FPW/FPD versions, it can be found there as well. On the sentiment "is this a intelligent specification": From FPx! based point of view it makes [a bit] more sense. You didn't have objects to pass around and the number of parameters to pass to functions is limited. Much of the handling done nowadays with private datasessions and/or buffering was done via sometimes global arrays [eminently safer than scatter/gather memvar IMHO], and sometimes these arrays had to be copied for "rollback" or check against changes.

Point 1: true "globals" have no need to be passed as parameters <g>
Point 2: Working in today's environment I put "global's" into public objects just for better design. If they are in objects, I can create a secondary object handle and can use this handle to pass as a parameter if I need the functionality Fabio is after -I can still call the original handle while passing another object handle down as parameter. So yes, seen from today's point of few, the implemented behaviour looks [even less] to be welcomed. But with today's current possibilities it shouldn't bother any more.

Personal opinion on the other bug [table fields passed by reference]:
I agree with Fabio that a macro - like using of only memvars for parameters passed by reference seems eminently more sensible.
I have no idea when/if the current behaviour was introduced or needed for dBase compatibility - which once was big selling point.
Basing code on error behaviour [which is a possibility I mentioned] is not "good coding" IMHO, but I'ld rather have possibility of upgrading code with no headache or elaborate verification before given the "go ahead" than trying to remember which "unlogical behaviour" was fixed in which version.

regards

thomas