Existe una limitación de 64k para un tamaño de un procedimiento en las versiones anteriores a VFP9. Fue eliminado a partir de VFP9. Sin embargo, quedó un fallo sin solucionar (y que MS no arreglará, como se puede ver en la conversación siguiente) y es que el uso de macros & está limitado a que se ejecuten en un procedimiento de tamaño inferior al límite anterior.
Errores que pueden aparecer:
- Error 36 – Command contains unrecognized phrase/keyword
- Error 1202 – Program too large
- VFP Crash.
Por tanto, es aconsejable:
- Dividir los procedimientos en tamaños inferiores a 64k, para no tener problemas con las macros.
- Usar EVALUATE tanto como se pueda, en lugar de sustituciones con &.
A continuación, adjunto un extracto de la conversación sobre este tema con MS. Al final, MS responde que NO arreglará el problema (el 5 septiembre de 2008).
You stated that in older versions of Visual FoxPro, the error: “Program is too large” would occur when trying to execute the compiled version of the program that was larger than 64k in size. This can cause a form to not execute and FoxPro crashes with the error when the form is loading.
You needed to know what to do about this error.
Environment (Hardware, Software, Technologies, etc.)
Visual FoxPro 9.0
Windows XP operating system
We have added a new command in VFP that will allow the code to run and not cause the “Program is too large” error. If you already have a text file called “Config.FPW” created in your folder where the VFP9.EXE is located, or in the folder where your custom EXE is located, you can add the following command to it:
PROGCACHE=0 && That is a zero.
If you do not have a Config.FPW text file, just create it with a text editor, and add the command above into it.
I will close this case as soon as you confirm that it works for you. Thank you for choosing Microsoft.
I have modified yet the CONFIG.FPW adding de PROGCACHE parameter with 0.
To be sure, I used the function SYS(3065) to see a 0 as response.
Then, I was modified the Method inside the form, and added more new lines to the code (in my case, I had replicated inside the method a simple lcVariable=””)
I just run the code, and it worked fine… until a macro substitution is executed. It is the same problem as before modifing the config.fpw
I deleted the new instructions added to crash the form, and run the form again. It does not do any error with the macro instruction.
When I removed the excess of code from the form method, it worked fine. But my need is to add more code inside those methods affected with this issue.
If I open now the method, and add (in my case) proximally 20 lines of code, if then I execute the form, it will give me unexpected errors, especially when the compiler execute the macro substitution.
The PROGCACHE parameter do not repair this issue.
At the begining of the case, I told you the message “program is too large” appears when I open the form in VFP6. It does not appear with VFP9 SP2. You only need to open the form with VFP9, fullfill of code the form, and save it. Then open it with VFP6, and VFP6 will give you the typical the message error “program is too large” (it is logical, because vfp6 do not allow to compile code bigger than 65kb). But what happend with VFP9 Sp2? VFP9 open and let you to add code to the form, and let you to execute the form FINE until it locate a macro substitution.
In VFP9 SP2, never appears a message lik “program too large”. It appears an error 36, or, simply, it crash VFP9 .
The code of the form have not any unrecognized pharese/keyword. It really works fine if you simply remove the new code.
We know Evaluate function is preferred to & command, but this form code is very old.
Sorry if my english is not so good.
I suspect that the macro substitution is not working because there is some limitation to it in FoxPro. The EVALUATE command must not be hitting that limitation.
I know that this code below is working a little different than your form, but it does work with macro substitution in it:
*Here is my code, it makes a 2 MB proc, builds exe.
CREATE PROJECT testxx nowait
CREATE form testxx DEFAULT nowait
xx = la_object
text to cCodeFragment noshow
n = n+1
cVar = ‘”set message to Alltrim(Str(n))”‘
cVar2 = &cVar
cstr = “local n”+Chr(13)+Chr(10)+”n = 0″+Chr(13)+Chr(10)
i = 0
nlen = 0
DO WHILE nlen < 2000000
i = i + 1
cstr = cstr + cCodeFragment
if Mod(i,100) = 0
set message to Alltrim(Str(nLen))
releas wind ‘form designer – testxx.scx’
TEXT TO lcText NOSHOW
on key label F5 clear events
?”Press F5 to exit”
do form testxx
DELETE FILE testxx.prg
lcRuncmd =”! /n “+Addbs(_vfp.defaultfilepath)+’testxx.exe’
We would not fix this in the FoxPro product since it is being retired.
I suspected the same as you. The macros have the old limit of 64kb. I am modifying the form to decrease the size of the methods, and replacing the & to Evaluate functions.
I executed your code and it works, but as you said, the code is a bit different, and it is not 100% applicable to my case.
When MS launched the SP1 of VFP9, we moved the APPs from VFP6 to VFP9 version. The first of the problems we found, were related also to & macros, we had some generic input data text classes. In those cases, I changed it to not use macros and it worked. I believed it was some kind of incompatibility (the methods where about 30 lines of code), and I modified the code to repair it. Another of the problems related to some headaches was the reports. VFP9 used the “save environment” as default value, and depending on driver of the printer, when by software you change the default printer in windows, VFP do not use it and always tried to print to the same printer. This was a big problem when you had a different printer to create PDFs or to send Faxes. We also used a workaround to give support to our customers with our defaults reports and reports modified by them.
I’m telling this to you, because as developers, we usually have a solution to our problems using some kind of workarounds. For me, to solve the problems related to our software, gives me a big satisfaction. Where I work, we have software developed a lot of years ago, and we are giving support to the customers until the end of the announced live of the product, repairing the errors, giving new product functions, etc. I can’t understand why Microsoft cannot do it. I work in a very small company, but MS is enough big to spend time and money to give real support to all of their products until the last day of the product’s life.
How are you?
I am sorry that we cannot “fix” the macro substitution problem.
But, as for your VFP 9.0 Reports only saving the Printer Environment issue, if you have it unselected under the REPORTS menu, your reports will print to any printer that you set VFP to with the SET PRINTER TO NAME <printer name> command.
If you use the CREATE REPORT command to create reports on the fly, the Printer Environment does not get saved. If so, just delete the contents of the first record’s TAG and TAG2 fields in the FRX file by opening the report with USE myreport.FRX and deleting the contents in the TAG and TAG2 fields (first record only).
You may not want the report to save the table(s) in the Data Environment of the report, and if so, just use the code below to get rid of the information that is entered into the “NAME” and “EXPR” memo fields that have a OBJTYPE value of “26”.
SET SAFETY OFF
CLOSE TABLES ALL
USE Employee IN 0 SHARED
CREATE REPORT DE_Test2.FRX FROM Employee.dbf FIELDS first_name
USE DE_Test2.FRX IN 0 EXCLUSIVE
DELETE FOR objtype = 26
REPORT FORM DE_Test2.FRX PREVIEW
I hope that this helps you with your FoxPro programming, and if you agree, we can close this case now.
I’m fine, thanks, I just come from 4 days of holidays!
Thanks for your comments about how to solve the reports problem. We did this solution when MS launched VFP9, it was when we began to distribute our applications compiled with VFP9. The reports problem came from old reports created with VFP5-6.
I am very satisfied with the quality of your answers, but not with Microsoft. I think Microsoft should repair those kind of the macro substitution problem until the last day the product life, as I told you in my last mail.
We are just at the beginning of the migration of our software to .NET – C#, but until we will finish this hard adventure, we must improve and give support to our old software, using VFP9. We can’t leave our customers to their luck because we are moving to new platforms and strategies.
Thanks for your help. If MS decide in a future to create a new SP3 to VFP9, please remember this case, I think it is enough important to add it in.