Phillip ---

Yes you can do it (if I understand you correctly). You can create DLL's as your plug-ins with a common property/method basic structure so that they can be queried by the core app as to function. Bad news: No UI components in a DLL.


>Okay, I finally got a hold of someone who could give me a definite answer on unix ports. They are no more. *sob* Oh well, I suppose I'll live. Probably easier than trying to cross-compile with the runtimes. (What a headache-causer THAT was! Can't say I'll miss THAT too much!;)
>
>Anyways, on to the subject at hand. I've got a *BIG* project I'm starting in on, and to have it work the way I'd like/need it to, I need to build something that I have NEVER done before in ANY version of FoxPro.
>
>A module/plugin-styled system. Sorta like Netscape plugins, but nowhere near it at the same time. These plugins will be semi-proprietary compiled databases and such that are downloaded off the net or something like that. Controlling a browser is easy, so I'm not worried about that. What I'm worried about is how to actually do this module thing. Can it even be done the way I've worked out below?
>

>coreInterpreter-> moduleInterpreter->Module
>moduleInterpreter-> moduleIdentifier-> ModuleIdentification
>moduleInterpreter-> moduleIndex-> ModuleIdentification
>

>My ascii-art flowcharting skills aren't the best, as you can see. ;) Basically, there's a core interpretation module, and the module interpreter. The module interpreter, which is just a glorified set of PGM's and such, is what actually reads the modules, and feeds them to the core interpreter, a happy visfoxpro application. :) But first, the module identifier identifies that it is indeed a compatible module, and the module index adds the module to it. This way the modules are kept track of and correctly indexed.
>
>Can it be done? Or am I better of doing a whole engine and such from scratch in c? ;) Any ideas, suggestions, pointers to examples of such implementations, etc greatly appreciated! Thanks! :)