>Reading the article "Getting the Power, Part 1" (may 2001 issue of FoxTalk http://www.pinnaclepublishing.com/FT/FTMag.nsf/0/E96FE3EFD33230D485256A4800536686!open&login), I couldn't understand (pardom my ignorance) the advantage of writing a FLL instead of a DLL. The only reason for using such type of library call (as I understood) was to bypass some of the problems VFP has with data types. The autor (Robert Abram) says:
>
>"But, FoxPro falls short in a few things I'd consider natural to have in a language. Those things would be native structure support, true pointer handling, and function callback ability, among others. Will FoxPro ever have those features? I can't say for sure, but I doubt it—some because they don't fit into the FoxPro as a language philosophy, others because they're not practical to add."
>
>Am I wrong or, if VFP had strong data typing, structures... (again!), perhaps we would have a better paved way to go, and wouldn't need FLLs at all?

The advantage of FLLs (which is a type of DLL) is that you can call its functions without having to resort to DECLARE, etc.

Also, from within the FLL, you now have access to the VFP API (ie. you can perform "low-level" VFP operations); a "standard" DLL cannot be used (easily) to access the VFP API.

If you need to manage structures, it's easier with an FLL; however, even if VFP supported structures natively, you might still use an FLL for performance reasons ... or to access VFP "internals" under circumstances that would not be practical otherwise.

On the other hand, if you don't mind coding a few DECLAREs and don't need access to the VFP API, then a DLL can suffice.