>With regard to Structs, it is possible to an extent to work around VFP's lack of support - not so with callbacks.
>
>One of the reasons VFP does not support callbacks is that the VFP source is not really compiled down to native code. I am making the assumption that this would be a prerequisite for callbacks to become an option, along with VFP not being so loosey-goosey with moving memory around dynamically.
>
>This post is not an argument in favor of native compilation and all that that would entail (possible loss of macros etc. - though I am actually in favor of ditching macros).
>
>It has occurred to me that whilst the VFP code that we developers create, lets refer to this as UDF's for the sake of simplicity, has the potential to move around in memory at runtime, making an AddressOf() function probably impossible to implement. The code that is running our UDF's i.e. the VFP run-time DLL is a lot less likely to move around once in memory, and is also native code.
>
>Rather than attempting to obtain a pointer to a UDF - would it not be simpler for the VFP runtime DLL to offer a new native function that allowed callbacks to indirect through itself (much like a proxy). Something like:

DECLARE Integer EnumWindows IN Win32API Long lpEnumFunc, Long lParam
>
>*- Initialise the call back.
>iResult = CALLBACK( "EnumWindows", "oTest.MyUDF", "Integer,Integer" )
>
>IF iResult = 0
>   *- Then callback failed to initialise.
>ENDIF

Syntax of CALLBACK()
>CALLBACK( cWin32FunctionName, cUdfToCall, cListOfParameters )
>
>cListOfParameters is a comma delimited list of data types that sould be passed through to cUdfToCall.
>
>cUdfToCall, when no more callbacks were expected, would be required to call CLEARCALLBACK().

Actually, if you're willing to put in a tiny bit of effort, callbacks are doable writing a small piece of code in another language. The first and oldest of these mechanisms is to create an FLL in C++ using the VFP API; the FLL would need to publish an entrypoint in itself for each type of callback; you'd get the address of the proper entrypoint from the .FLL as an integer, and then pass that as an integer to the API function. The .FLL would receive the callback, and could then populate VFP memory variables or fields in a cursor; an FLL can directly manipulate the VFP runtime environment. Christof Lange published the VC++ source of an FLL to do just this around 3-4 years ago. It requires working in C++, but most of the work is already done. Obviously, the FLL needs to ship with the app.

The same type of thing could be done with an ActiveX component; the ActiveX component would publish an entrypoint, and populate a collection with results, and can surface an event that VFP could respond to. Again, it involves working in another language like C++ or VB (Dan Appleman's first Win32 API book for VB included sample source code forworking with several types of callbacks), and the component would have to be registered on each target system.

You'll find that the need for callbacks will lessen as the Windows environment evolves - many enumerations can be accomplished using the WMI, and we'll be able to access .NET resources via an Interop layer at worst in the VS.NET release of VFP, and in all likelihood, VFP6 will have some capability to use Interop-wrapped .NET services via COM. We'll know more when the VS.NET beta actually ships. In the meanwhile, you can simply use tools other than VFP to manage C-style DLLs requiring a callback, and expose the services and results through one of the many existing interfacing options like FLLs, C DLLs or COM.