There is program that does that.
Search downloads & threads here on 'PrgToVcx' ...
Sure something will come up.
I used it once (in order to suit people like you) and it worked ok.


>I want to do the opposite - take prg based class and move it back to VCX. What should I use?
>
>Thanks.
>
>>>
>>>I'm doing the same for several reasons - first, I agree it's easier to go down the code in a prg (I've been doing it in both visual and prg classes for years - and have to confess .prg is easier to handle).
>>
>>Aldough this way is not all that popular arround here, I find prg's also
>>much easier to handle then having to dig trough form methods.
>>
>>I find myself perfect solution with session objects written in prg where all BOs are stored. One prg per project.
>>
>>So I wld create session object (subclass) and from in there call
>>all forms needed to show up, passing entire session object as parametar
>>to each form. Each form gets it in init method, and stores that object reference to reserved property called 'dataengine'.
>>After that all forms do is call methods within session object via that property.
>>
>>

>>
>>*** BO Calling Form
>>do form myform.scx with this
>>
>>* And then later that form calling back BO
>>thisform.dataengine.do_something()
>>
>>

>>
>>As you said, some form sode is needed to handle few quirks here and there bat that's about it. Everything is actually happening inside BO; opening of the tables calculations, record validations, saving etc , while form is just dummy, nicely polished surface shown to the user.
>>Parental session class is equiped/responsible for saving, transaction processing, buffering and other data related stuff.
>>
>>I rewrote my own framework almost comletely (session object came later with VFP6sp3) to take advantage of this concept.
>>
>>Works perfect for me :)
>>
>>
>>>
>>>>How do I load a non-visual class onto the form? Do I instantiate it in the load method? Once the form is open how does the form call the object?
>>>
>>>At my current job the form class has a property which holds the name of the bizobject class to load, and it does that at .load() time, something like this:
>>>
>>>

this.newobject("oBz", this.cBizClass, forceext(this.cbizclass, "prg"))

>>>
>>>This means that there's some discipline and naming convention - any bizobject is defined in a .prg named the same as the class.
>>>Then anywhere in form's code, form calls ThisForm.oBz.SomeMethod().
>>>When creating a new form, you need only to fill the .cBizClass property, drop controls and set their controlsources. And don't forget the form.caption :).
>>>Most of my forms have no code at all. The few that have, have very little - a few weird grids that need special handling, .when() on a couple of odd columns, a button which stays enabled when other buttons don't has a whole line in its .refresh(), and that's it.
>>>
>>>>For instance I have a validateform method that checks to see all the required fields are filled in, there are no duplicate keys in the table, and at least one checkbox is marked defining the record type. When I move this method into the object how do I call it and since the object loads on the form will the object see all the controls on the form?
>>>
>>>It will, but even better... the control can pass itself as a parameter, so the bizobject doesn't really need to know the name of the control. So in any control's valid you need only
>>>
>>>

return thisform.obz.lValidate(this)

>>>
>>>and your lValidate, of course, begins with
>>>

procedure lValidate(oControl)
>>>uValue=getpem(oControl, "value")
>>>cSource=getpem(oControl, "controlsource")
>>>

>>>...etc etc. We usually have the validation code as a case statement - one case for each possible controlsource on the form.
>>>
>>>>Since the form is subclassed I could even establish a naming convention and give the business object the same name as the form so that when form ‘frmResource’ opens it loads non-visual object ‘frmResourceObj.prg’
>>>
>>>In our convention it would be bzResource.prg - but the idea is the same.