>Hi all
>
>During the FPD days I remember creating a .APP which contained all the codes of my framework. I had an app specific main.prg (with dummy function header of actual functions in the .app to avoid compile errors), it would then in turn DO fwmain.prg IN myapp.app
>
>So any project with it's specific screens, reports, etc. and this .app would be all that would be required to develop. This allowed me to separate the framework standard codes into a project and modified only when required. Plus this, though I never successfully got round to it, allowed me to have a junior developer under me to work on a project but hiding the framework codes from inadvertent or quick-fix code changes.
>
>Is this possible still in VFP9 and OOP?
1) You still can call procedures form other APP using "DO fwmain.prg IN myapp.app"
2) You can istantiate objects of classes defined in external APP using either NEWOBJECT() or call to procedure which instantiate that object and returns pointer. I recomend the second approach because NEWOBJECT() fails to incorporate graphics and other files compiled to external APP.
3) But you cannot subclass classes defined in external APP. Hovewer, you can use directory of shared class libraries. This is how I do.
/A new technology turns into completely outdated stuff before you have a time to read "Getting Started..." section.
/If there are some "system programmers" then others are unsystematic.