Common Procedure file vs. Common Class File 1

[Scott24x7]

In my Fox2.6 days, I had a lengthy file called &quot;COMMON.PRG&quot;, which I would set with the SET PROCEDURE TO <proc> in fox. This had all my handy-dandy UDF's that I'd call, as well as my ERROR Handler, and SYSTEM INITIALIZATIONs. As I get deeper into VFP, I find that I can now put those items into a &quot;Custom&quot; class. That then gets (here's where I get hazey...) &quot;Instantiated&quot; in my &quot;MAIN&quot; form, and then everything can get at these functions as they could before. Is this a good idea? Should I stick with a .PRG, or should I class these items? What is the advantage/disadvantage? Is it hard?
I think the thing that is killing me is, I have been a really good 2.6 developer, and I don't want to start some bad habbits that will cause me huge problems later. What's the pannels suggestion for this one???
Many thanks,
-Scott

 

[ramani]

Hi

When you put small small routines in a myPRG and then
SET PROCEDUTRE TO myPRG
this works fine in VFP6 as well.

However, the major advantage you get when you put in a class, is the advantage of bending the procedure to your convenience as per the specific form needs.
DODEFAULT()
NODEFAULT
is the great advantage when you sub class from the main class and bend these routines to the need of circumstances. In a procedure file, either you do the procedure or rewrire the procedure with all the conditional parameters passed into it. However when you class it and subclass it, either you can do it or conditionaly escape without doing it, in that sub class.

SO my advice will be to slowly build your classes and adapt them.

Best of luck

ramani :-9
(Subramanian.G)
FoxAcc
ramani_g@yahoo.com
LET KNOW IF THIS HELPED. ENOUGH EXPERTS ARE HERE TO HELP YOU OUT! BEST OF LUCK

 

[TomasDill]

Hi!

It is good idea to keep them in PRG. From what I remember, somebody ran a test that show the speed of calling the VFP procedure declared by different ways. the most speed has the procedure or UDF declared in the PRG file and set by SET PROCEDURE. I guess MS did optimized this case because these UDF's in a common PRG file are used the most oftenly and thus require the most speed.


Vlad Grynchyshyn
vgryn@softserve.lviv.ua

http://www.softservecom.com

The professional level of programmer could be determined by level of stupidity of his/her bugs

 

[weedz]

What I have done in my private application (CrownBase) is to design all my classes using the visual class designer. I have my general procedures in a PRG file and I have my menu in a PRG file as well.

When I build an exe file I use a project hook and the class browser to put all my code into one giant PRG and compile this one to an FXP (VCX -> PRG, procerdue prg's and menu prg's).

The advantage to this practice is that I only have to issue a 'set procedure to' once and in my development environment I still have all classes and procedures logically split so I still have easy acccess to them.

When you are working in a giant project and you are compiling all visual classes into your exe, you get:
1. A giant exe
2. When you have many classlibraries you will have to issue SET CLASSLIB many times, causing the app to instatiate much slower.

In CrownBase, it starts very quickly because all application logic can be found in one PRG at runtime.

See link in my signature.

HTH,
Weedz (Wietze Veld)
My private project:

http://www.crowncap.demon.nl\info\crwnbase

And especially for VFP rookies:

http://fox.wikis.com/wc.dll?Wiki~VFPRookieMistakes~VFP

 

[ThomC]

<<In my Fox2.6 days, I had a lengthy file alled &quot;COMMON.PRG&quot;, which I would set with the SET PROCEDURE TO <proc> in fox.
This had all my handy-dandy UDF's that I'd call, as well as my ERROR Handler, and SYSTEM INITIALIZATIONs.
As I get deeper into VFP, I find that I can now put those items into a &quot;Custom&quot; class.
That then gets (here's where I get hazey...) &quot;Instantiated&quot; in my &quot;MAIN&quot; form, and then everything can get at these
functions as they could before. Is this a good idea? Should I stick with a .PRG, or should I class these items?
What is the advantage/disadvantage? Is it hard?
I think the thing that is killing me is, I have been a really good 2.6 developer, and I don't want to start
some bad habbits that will cause me huge problems later. What's the pannels suggestion for this one???>>


There are a number of advantages to using OOP instead of the tried and true procedural route. Some of the advantages are immediate, some will only apply in a more advanced environment.

Personally, I hate SET PROC TO. I've always considered it a nasty old xBase kludge. It drives me crazy when a function is called in a piece of code and the function is part of a SET PROC TO that encompasses a half-dozen program files. How do you tell which file has the (usually offending) function?
An OOP alternative is:

*** MyCustom.prg
RETURN CREATEOBJECT(&quot;MyCustom&quot

DEFINE CLASS MyCustom AS CUSTOM
pcSysDrive = &quot;&quot;
pcRootPath = &quot;&quot;
PROTECTED pnCriticalVal = 0
roAdoRS = &quot;&quot;
roAdoConnection = &quot;&quot;
*** and what ever other properties you need

FUNCTION SetEnvironment
WITH THIS
.pcSysDrive = SYS(5)
.pcRootPath = SYS(2003)
ENDWITH
RETURN

FUNCTION OpenDBF
LPARAMETERS tcDBF, txOrder, txWorkSpace
*** your tried and true &quot;open a DBF&quot; code goes here
RETURN

FUNCTION CloseDBF
*** your tried and true &quot;close a DBF&quot; code goes here
RETURN

FUNCTION OpenADO
*** open an ADO record set
RETURN

FUNCTION MoveADO
*** navigate through an ADO record set
RETURN

FUNCTION CloseADO
*** close an ADO record set
RETURN

FUNCTION MyUltraTrickStuff_1
*** your tried and true ultra trick code goes here
RETURN

FUNCTION SetCriticalVal
LPARAMETER vnNewVal
IF VARTYPE(m.vnNewVal) = &quot;N&quot;
THIS.pnCriticalVal = m.vnNewVal
ENDIF
RETURN

*** etc, etc, etc
ENDDEFINE
*** End of MyCustom.prg



*** MyApp.prg

*** initialize the memvar that will hold your custom-class object
goCust = &quot;&quot;
*** load your custom-class into the memvar... aka &quot;Instantiation&quot;
DO MyCustom.prg WITH goCust

WITH goCust
.SetEnvironment()
.OpenDBF(&quot;MyDBF&quot;, &quot;MyTag&quot
.OpenDBF(&quot;My2ndDBF&quot;, &quot;Tag2&quot;, 2)
ENDWITH

*** other code may go here...

goCust.MyUltraTrickStuff_1()

RETURN
*** End of MyApp.prg


First off, this is what's happend in this example:
MyCustom.prg has a bunch of properties (formerly your global memvars) and functions/methods (formerly your functions/procedures).
MyApp.prg initializes a memvar (goCust) which is fed to MyCustom.prg. MyCustom creates the &quot;custom&quot; object, which is stored in goCust. (ENORMOUS subtlty here... MyCustom.prg functionally has only one line of code: RETURN CREATEOBJECT(&quot;MyCustom&quot; but this one line of code calls the DEFINE OBJECT, which builds the MyCustom object).
On returing from MyCustom.prg, all the properties and methods in MyCustom.prg are accessible via the goCust memvar.
Because goCust was declared at the beginning of MyApp.prg, it is scoped to all of MyApp.prg and any programs, forms, menus, etc. that are called by MyApp. Its functionally the same as defining goApp as PUBLIC, without the overhead.


In this very simple example, the good stuff in your old procedure file is now available in the goCust object with the advantage that you can (fairly) easily track where the procedures are coming from... OOP tends to be self-documenting. Notice that there was no &quot;SET&quot; required to call the class-creation program (DO MyCustom.prg WITH...)

Also, critical information (in this example, the system drive and root directory) are stored in one place... the custom object.

At this point, you may be saying &quot;So what? There's nothing here that I haven't already done in procedural Fox code&quot;
But there are things available via OOP that you can't do procedurally. For example, ever had a global memvar overwritten in some procedure, which caused everything to go BOOM? Remember how hard it was to track it down?
If that global memvar became a protected property of your custom class, it COULDN'T be changed unless you changed it
from within the class. Typically, that change is done with a method of the class (i.e. goCust.SetCriticalVal()).
That method becomes something known as a class &quot;interface&quot;, one of the OOP mechanism used to improve the encapsulation (formerly known as modularity) of your code.


As Microsoft's stuff becomes more interoperable, you may find yourself using things outside of VFP. It used to be really tough because VFP didn't play nice with ActiveX components, but VFP 7 is supposed to have much improved COM/DCOM support. Which is good... very good. If you're really carefull with your class encapsulation, you'll be able to start reusing your VFP components in other strange and unexpected places, making your life much more interesting (no suprise there) and easier (huge suprise!). This is the REAL benefit of utilizing OOP.

HTH,
Thom C.