The "main" is simply the entry point if the .APP gets called directly. In addition to this, functions and procedures in the "main" program file are visible through the DO ... IN .... For example, if we had MYLIB1.APP has MYLIB1.PRG as the "main", and you have the following:
* Contents of MYLIB1.PRG
RETURN "MYLIB1 - rev 2003.02.21" && Provide means to identify revision
PROCEDURE MyProc1
WAIT WINDOW "MyProc1"
ENDPROC
PROCEDURE MyProc2
WAIT WINDOW "MyProc2"
ENDPROC
FUNCTION MyFunc1
RETURN "This string returned MyFunc1"
ENDFUNC
Then you could do the following in an external program:
DO MyProc1 IN MYLIB1.APP
Or another thing you could do:
SET PROCEDURE TO MyLib.APP ADDITIVE
? MyFunc1()
What's more, if you define classes programmatically within the main .PRG and you SET PROCEDURE to the .APP, that class definition becomes available for use. This means you'll be able to use CREATEOBJECT() to create an instance. This feature is one way you can get around the problem about distributing programs using VCX files, as you'll either have to build them into each .APP that uses them (resulting in undesirable bloating), or distrubite the .VCX separately (no need to decompile -- it's directly readable if someone has VFP).
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only