Mark,

Yes, I thought about it too. It it uses form's objects or form itself, it has to be a form method (we can pass a form reference in the program, if we want to make it external).

E.g.
GeneratedMethodOnTheFly

lparameters toForm 
....
return

invokation: do GeneratedMethodOnTheFly(thisform)

I don't think, though, it's a good practice to do this...



>>Or you can try:
>>
>>strtofile(table1.memofield, 'c:\apractic\junk\table1.prg')
>>compile 'c:\apractic\junk\table1.prg'
>>do 'c:\apractic\junk\table1.prg'
>
>That is well and good, but his example had commands like THISFORM in it. You will get errors compiling and running an external PRG. You would have to change it to something like _Screen.ActiveForm. However, I am not quite sure why anyone would want to do it that way intead of just putting generic code in a method in the form or appropriate control. If you wanted to make the property options data-driven, I would have a table with FormName, Property and PropValue fields that would contain the appropriate values instead of storing an entire command line in a table.