>George,
>
>>>snip<<
>
>>Well, we
can hope.< g > Seriously, I'd really like to hear what Ed R. has to say about this. He's the guy that can give better insights to the ramifications of something like this.
>
>Ed's too darn smart. *G*
I want that in writing...
>
>>In some ways, component design utilizing dynamic linking makes things much easier to deal with. Back in FPW all my applications were APP files that were started by a single EXE. The EXE contained all the system level services (opening tables, printing reports, handling the command bar, handling searches, etc.) required by the apps. The apps accessed the services by utilizing dynamic linking. These (the services) were included in the Project Manager for the apps, but marked as excluded. If a change was required in one of these services, all I had to do was re-compile the main EXE and turn over one file to impact all the applications.
>>
>>N-Tier offers a whole new realm of possibilities in this area, since it can potentially allow us to interact with other applications, which may or may not be based on the VFP development platform.
>
n-Tier is great. It's important to realize that we can write an n-tier app entirely in VFP. You can define tier boundaries and use classes to implement the logical components, and rely on the class interface (properties and methods) to encapsulate functionality and provide the tier layering there. If you need to swap in something else that isn't VFP, fine; compile your layers as COM objects that have methods and properties that are the same as the VFP class it replaces. The only thing that changes is how the component is installed and how the object gets created. The interface stays the same, and so does the app.
>Right. Alan Schwartz, formerly of FoxFire! fame had a nifty little
trick he used to link multiple .APP files. He's call a dummy procedure the first one which would return to the calling EXE, ehich would then call the 2nd through the nth. By so doing FoxPro registered all the procedures and functions and knew where to find them. It was the "then" version of today's DLL essentially.
>
>Best,
