Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
How to move Form Methods to .prg as non-visual class?
Message
From
21/03/2006 21:35:29
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
 
To
21/03/2006 18:09:12
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows 2000
Network:
Novell 5.x
Database:
MS SQL Server
Miscellaneous
Thread ID:
01106452
Message ID:
01106474
Views:
20
This message has been marked as the solution to the initial question of the thread.
>I am writing a system and want to strip the code out of the form methods and put it in a .prg file. The forms are already sub-classed from a parent form so they inherit all the common properties and method names they need to work with a dataclass for the application. I prefer to edit methods outside of forms because I have bad vision so I keep my resolution low and don't have much screen editing space. I can also find mistakes faster in a .prg file. There are customer 27 methods on each form that need to be edited for the table the form is using, and I think it will much easier to manage them in the .prg.
>
>I have read several threads on this (827299, 415216, 314465, 331088, 70069) and it sounds like the best way to do this is to make a business object for the table the form is working with and load that class on the form.

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).

>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.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform