>Erik, I am sorry if my posts are not crystal clear (I am French Canadian
>and did not start using English extensively until 6 years ago). About
>half my assignments involve solving some real-time problem and most of
>these involve some serious security issues (even death can be a possible
>result). I usually work with a team of engineers/programmers/attorneys
>and we try to make the systems as fool-proof as possible. I have used
>VFP extensively for the past 5.5 years and I have started to like it.
>Unfortunately, I don't use it as often as I wish because if an attorney
>raises a security issue that may cause the client to be liable and I
>don't know how to do it in VFP, I use something else.

This sounds like you are looking at the problem from the same viewpoint as myself. A lot of my work has safety critical issues, where death or serious injury could occur if software fails. In an ideal world, I would follow all of the guidelines & there would be no problem. Unfortunately, programmers do make mistakes & sometimes these mistakes are not picked up at development time - especially in a real-time environment. If breaking some of the rules makes the software safer, at the expense of later adaptability, then I believe that is the correct route to go. Why trust a programmer to pass a parameter correctly, when the information contained in that parameter is easily obtained from the system. If it meant digging around in obscure function calls, using 3rd party s/w, it would be a different matter. (Also note, that I originally put my comments in, as a general viewpoint not directly related to VfP - and I certainly wouldn't put any VfP stuff at safety critical points in the system - it's far to unreliable).

Aside from the above, I still can't really see the difference in passing the form name by parameter, or getting it from a system call. If the routine needs it, why does it matter how it gets it ?