>I want to ship compiled code to be used with a desk top exe. The procecures are created from tabular data. -- case statements based on logic that must be evaluated sequentially -- Since the rules are based on many different variables, the determination of a result is not as simple as a single or even multi key lookup. I created an fxp file that produced a huge preformance improvement. Now it isseven times faster than a looping structure that sequentially evaluates sets of rules. The rules are produced in a 5 table join. Now I am able to do the joins in the creation of the fxp rather than at runtime. I think speed also results from logic evaluation in the compiled code rather than through parsing of words in the case statements.
>
>Now I'm wondering what is the best suggestion for accessing the code at runtime. I may not be able to get the code included in the exe and the application doesn't use a container (no stored procedures). It seems that there are 6 options. What are the pros and cons?
>
>1. Set procedure to the fxp. Nested cases.
>2. Set procedure to the fxp. Many Procs within the fxp.
>3. Create a prg-based class with many methods.
>4. Create a vcx with many classes? (Having trouble with this because when I run the following code, the class is not recognized when I try to instantiate it.
>
>(xxxproc is the foxpro code
>propstring is a list of properties)
>
>thisclass = "xyz"
>CREATE CLASS &thisclass OF carcalc as "Custom"
>USE carcalc.vcx
>LOCATE for objname = thisclass AND baseclass ="custom"
>REPLACE methods with xxxproc,PROPERTIES WITH PROPSTRING,RESERVED1 WITH "Class",Reserved1 WITH "1"
Haven't tried this. Maybe you also need
USE
compile classlib carcalc
That would create the content in the objcode field.
>5. Execscript on memo fields.
>6. Put compiled code in memo fields,write to file, and execute.
You can even put source code into memo fields, reversibly encrypted if you want, copy out into a .prg, compile and run. Which isn't really too different from (5). Also the .prg in a xml file would be an option, if distribution of the file is a concern.
>The VCX seems like a good place to put the code. I would probably eliminate the readable code and ship only the compiled code. I just can't get the right method to make it.
The trouble with shipping a vcx is that it's actually two files - but then you can also ship that as a xml, and have a xmltocursor() in the app, which would then copy to your.vcx and create object(s) from it.
Frankly, any of these would work as methods of transport; it's more the matter of what's easier for you in development, i.e. which is easier to maintain.