>Hi!
>
>Something like following:
>
>
>#DEFINE CRLF chr(13)+chr(10)
>
>
>lcMyPRG = "DEFINE CLASS MyClass AS Custom" + CRLF + ;
>"PROCEDURE DoSomeCode" + CRLF + ;
>MyAlias.MyMemoFieldWithCode + CRLF + ;
>"ENDPROC" + CRLF + ;
>"ENDDEFINE" + CRLF
>
>
>strtofile(lcMyPRG,"TempPRG.PRG")
>compile TempPRG.PRG
>set proc to TempPRG.PRG ADDITIVE
>
>thisform.AddObject("TempObject","MyClass")
>
>
>
>= thisform.TempObject.DoSomeCode()
>
>thisform.RemoveObject("TempObject")
>RELEASE PROCEDURE TempPRG.PRG
>
>
Great, this is what I thought - a new custom object defined on the fly. Very clever!
BTW, you don't need to set and release procedure if you will use NewObject method (VFP6.0 and greater).
>>>Hi!
>>>
>>>Definitely you can wrap the code into the method inside of the DEFINE CLASS construction. Than use generated PRG file to put custom control on the form. Than call a method - thisform is available.
>>>
>>>HTH.
>>>
>>
>>Vlad,
>>
>>I'm not sure, I understood your idea, could you please elaborate more?
>>
>>Thanks in advance.
>>>
>>>
>>>
>>>>>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.
If it's not broken, fix it until it is.
My Blog