>>
>>Dmitry,
>>ExecScript is easy but however it is slow and problematic at runtime (it's compiled with each call and if you need referencing other project elements -like a form,class antoher prg etc- then execscript cannot see them).
>>For a similar necessity (sounds similar to me) what I did was to create a "dispatcher" code. What that code does is to call required proc/form with given parameters. A table which is included in exe holds proc/function calls as strings. ie:
>>
>>ActionID#1,doForm("myForm",myParameters)
>>ActionID#2,libProcedure("myProcedure",myParameters)
>
>Cetin,
>
>I see now from your message here and another thread that Naomi pointed where you came across some problems with EXECSCRIPT. I will consider your approach of using what you call a "dispatcher" code. I am also looking into using COMPILE command. And Fabio made an insteresting suggestion of storing the compiled code in the memo field, I never thought of that. So I have many options now to consider.
>
>Thank you for your help.

And when the memo field gets corrupted, as so often happens, you will need a way to retrieve the .PRG recompile it and repopulate the memo field. Why not make it infinitely easier on your self and use individual .PRGs.

Another suggestion: use a factory object. This factory will create the final object - I understand instantiation times may be a problem. Accessing a method is slower than a .UDF. The final object will hold a method instead of the .PRG. This object can be based on a class which has the default behavior. Subclasses of this object can have specific behaviors.

In that way, you may be able to reduce the total number of .PRGs by reorganizing them into a hierarchy of similar cases.