Ask 4 Foxpro programmers how to do a main.prg or application start in general, and you get 12 answers
.
When using an application framework to build your application it's simpler, as you simply apply to the rules of that framework.
Even though the FFC "framework" and wizards coming with foxpro are in general not a good one, you can have a look at the project templates in the component gallery. You find it in the Tools menu.
Start it, then choose Visual Foxpro Catalog->Templates->Applications
Choosing the Books Template, specifying a project name "mybooks" and a directory where to generate this you get a main prg named as you name the project in the code tab.
This could be a starter. It has some good things in it, like setting an errorhandler and creating an application object.
Some things are not that obvious, as they are done within that application object goApp or better said are coded in the cApplication class. For example the main menu and main form are shown in the show() method of the cApplication class and the READ EVENTS is in there, too. Actually quite clever.
One thing in a typically main.prg also is the end code of the application. The template projects have a cleanup routine in their main.prg I wouldn't do. I prefer ON SHUTDOQN QUIT instead of such a cleanup routine, as most things are done automatically anyway on exit of the foxpro runtime, like closing all file handles to tables, databases etc., rolling back all open transactions and more. Even in case of an ungracful shutdown via C5 error.
I rather prefer a decent Destroy code in the individual classes, which means holding on to the OOP principle of encapsulation of course. If a class or an instance of it does not know how to cleanup itself, then who should?
In general going the oop route, you can put quite much of such a main.prg into an application class instead of doing it seperate before going into "OOP mode" so to say.
But one thing is actually very strong and stable: Because the main.prg is the start and does not finish (or else the application would exit right away), it's the one thing always on the call stack (see SYS(16,0)).
Any private variable you set here is quasi public. That also is true for procedures and functions and class definitions in main.prg, nevertheless this does not mean to put everything into it you could use in general, keep it lean.
If you want a procedure ON SHUTDOWN triggers, this should actually be in here, as you can be sure nothing but the runtime exit puts that code off the stack. In contrast: A false CLEAR CLASS in your code, and some cleanup class would fail to instanciate.
Basics are of course setting up errorhandling and shutdown behavior, environment settings, classlibs and procedures. But all this could also be done by objects, either goApp or subobjects of it.
Eg setting classlibs could also be done by a factory (see design patters), which is an object used for all other object generation throughout the whole application.
Also environment settings (SET commands) I'd not do in main.prg, but in a class which does store the previous values in it's init and reverts to these values in it's destroy. This also helps repeating the settings in any private datasession, as some settings are done per datasession.
No matter where you put things, of course you need some things done in the right order, eg READ EVENTS as last thing of the start (but of course any finishing code afterwards, if you want).
First I'd be caring for errorhandling and shutdown (either QUIT or some cleanup), then you need some way of setting classlibs - unless always working with Newobject() - and procedures, before you can create an object, of course.
Then you make some environment settings, directly or in an object. Finally start a menu (if), start a main form (if) and READ EVENTS. And don't forget you need something to also trigger CLEAR EVENTS.
Bye, Olaf.
