A place to discuss the pros and cons of using PRGs vs VCXes for storing classes.

---

Issue	PRG	VCX	Winner
Packaging	Single file package	Double file package	PRG has less files to keep track of
Format of storage	Simple text	DBF/FPT file format	The PRG has an advantage for exchanging files as it is simple text. PRG works better with source control software.
Compilation	Compiles to an FXP file and it can be compiled while the PRG is read-only	Compiles within the VCX/VCT files. If the VCX is opened read-only the library can not be compiled.	Not sure how important compiling while read-only is, but since the PRG can and the VCX cannot I guess the PRG wins this one.
Multideveloper	Allow multiple developers to work on the same library	Using source control and each developer having their own copy, the same can happen with the VCX.	In either case having more than one developer working on the same library has to be well managed or else serious versioning problems can occur. No clear winner on this point.
Comparing versions	Is easily compared with previous versions using any of the many file compare utilities.	Can also be compared but it is much more difficult to see the differences clearly.	PRG wins this point.
Hold Functions	Can contain both class definitions and function definitions	Can only store class definitions	Not sure if mixing class defs with function defs is a good thing. If it is then the PRG wins this point.
VFP Last Copy Idiom	Can use it	Cannot use it	PRG wins
Compiler Directives	Can be used to include or exclude class components (Methods/Properties)	Cannot effect the class components	PRG Wins
Comments	Easily included	Easily included	No clear winner
Corruption	Being simple text types of corruption possible is less	More possible types of corruption	Not sure how important the number of types of corruption is, if a file becomes corrupt then it really doesn't matter much how badly it is corrupted, it must be repaired. Simple text files can be more easily repaired if there is anything left so I guess we have to give the PRG a point for this one.
Viewing code	We can view multiple methods in a single editor window (if the methods are short enough and located in the same part of the file to see more than one at a time)	We can view multiple methods in separate editor windows	~VCX advantage (this one really a matter of personal preference)
Viewing code while a class is in memory	Can be done (but the code cannot be compiled as the FXP is in use)	Cannot be done, all classes in the library must be cleared from memory before the VCX can be opened	Again, not sure how important it is to "see" the code if you cannot edit it and compile the changes. If seeing the code is important then the prg wins here.
Choice of editors	You have a choice	You do not have a choice	PRG wins
Personal Comfort	Some developers prefer this	Some developers prefer this	No clear winner
Moving code from one class to another	Can copy/paste code from one class to another	Not really all that difficult to do this here by opening the two classes and copy/paste between them	No clear winner
Source Protection	Ship only the FXP	Clear the Methods field with a USE Thelib.vcx REPLACE ALL Methods WITH ""	No clear winner, decompilers work on either
Certain Classes	Certain VFP base classes can only be subclassed in a PRG	N/A	PRG wins for those base classes
Testing	A PRG class definition can have the testing code in the same prg before the class is defined. Then DO TheClass.prg will runs the test suite. Example: * SomePrg.PRG x=CREATE("SomeClass") ? "The following should return .T." ?x.method1() ? "The following should return .F." ?x.method2() DEFINE CLASS SomeClass * just for example FUNCTION Method1 FUNCTION Method2 RETURN .F. ENDDEFINE	Needs an external testing prg to run a test suite	PRG wins
COM Servers	Most of the recent enhancements for COM servers in VFP 7 are only possible in a prg	N/A	PRG wins
Changing parent class	Simple edit of the DEFINE CLASS line	Requires opening the VCX as a table and editing the data or the use of the class browser.	PRG wins
Property sheet	None ( The 'Document View' might be considered the poorer cousin of a property sheet; at least you can easily find stuff.)	Has one	VCX wins
Automated processing of the code	Can be done	Easier to do because VFP enforces structure in the Methods and Properties memos	VCX advantage
Using the designers	Cannot	Can	VCX wins
Subclassing ActiveX controls	Can be done but it is difficult as the determination and entering of the runtime license is complex	Easier to do	VCX wins
Intellisense	Must create custom stuff for handling things like THIS and THISFORM etc	Natively handles these items	VCX wins
preprocessor sensitivty	doesn't care about mismatched preprocessor directives	VFP warns when #IF is used without corresponding #ENDIF. Ignoring this warning causes method corruption. Fixing requires manual editing in VCX file.

Some of the above items and "winners" are truly subjective.

Also, I don't think it really matters. As a developer, you get to chose your weapons. Knowing the pros and cons is the important part, not what someone else thinks is more important. When it comes time to go into battle, examine the playing field and choose wisely. -- cfk

---

See also Inheritance In VFP

---

Contributors: Steven Black, Randy Pearson, Marty Smith, Alex Feldstein, Roxanne Seibert, Paul Borowicz, df, Christof Wollenhaupt

---

Refactored on June 29, 2002 by Jim Booth

---

Category Principles And Guidelines Category Checklists Category Coding Category Class Design