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().