The other bit that was a headache was dealing with one of the hazards of a program that wasn't a monolithic EXE. The program divided into separate .APP and .FXP modules (partly because we wanted to avoid having to recompile each time we'd updated a module, and also as a practical issue of being able to provide updates on floppy diskette). One twist that crops up are with date constants of {1/2/3} format (yes I'm aware of the {^y.m.d} syntax -- but that wasn't availabe in FPD and FPW) -- where the interpretation would depend on the date format setting at compile time. This meant the possibility of an identical line of code in different modules could have different interpretations!

One thing that usually had me pulling my hair out was how dBASE handled variables that were passed as parameters. rather than being aliased as in many other languages (so that the same value would be accessed by more than one name), the passed variable would still be accessible and seemingly operate independent of the paramerter value until return from the subprocedure. This often resulted in difficult-to-trace bugs, or really hard-to-debug.code when this behavior was utilised. The switch to FoxPro helped a lot with that issue (since it hides the passed variable).

>You have my sympathy! :-)
>
>One of the worst cases I have worked with, was a project with many procedure files in different directories. The project had many functions with identical names, so it was no big surprise that the application acted weird from time to time. I worked my way through all the files and separated most of the functions into separate files in ONE prog directory. During this work I got a series of "do you want to overwrite" messages, which told me which function calls to search for. And as a side effect, I learned to appreciate Code Reference.
>
>>I've run into problems where not only were identically-named functions (which resulted in hard-to-diagnose problems -- depending on the conditions you might fet a different one being called), but within one context the name would resolve to an array variable. It's one of those things I had to learn to deal with when dealing with program code that had been worked on by several different programmers that practiced "cut-and-paste" coding (i.e. copy sections of code from one place, then applying minimal changes to get it working within another context -- a real headache as usually none of the variable and function names have anything to do with the context they appear).
>>
>>>I'm glad you solved the problem. Having functions with the same name can be a PITA, that's one of the reasons why I now mostly use separate files for every function.
>>>
>>>>Found where was an error:
>>>>there was two .prg files where was declared two different functions with same name - one with PARAMETERS statements, other without... It's strange how compiler alloyed to compile the code... :-?
>>>>
>>>>>You must try to isolate the error, exactly what line of code triggers the error.
>>>>>
>>>>>>Without any parameters.
>>>>>>The problem occurs sometimes working with forms...
>>>>>>
>>>>>>>How do you start the exe, do you add parameters?
>>>>>>>
>>>>>>>>It's compiled with Debug info, but Error doesn't give any information about line...
>>>>>>>>
>>>>>>>>>Compile the exe with debug info, and see which line causes the error.
>>>>>>>>>
>>>>>>>>>>Hello,
>>>>>>>>>>
>>>>>>>>>>I have strange behavior of my compiled exe file.
>>>>>>>>>>
>>>>>>>>>>I'm getting "No PARAMETERS statement is found" error where it can't be...
>>>>>>>>>>
>>>>>>>>>>Why this error occurs?