Allows calling a .NET method and executing it asynchronously on a background thread. This is useful for long running operations that take a long time to complete, or if you need to run many simultaneous operations at the same time.

Uses the AsyncCallbackEvents class to receive notifications when requests complete or fail (see example).


Return Value



A callback events object that must have the following methods that fire when the respective events are fired:

  • OnCompleted(lvResult, lcMethod)
  • OnError(lcErrorMessage, loException, lcMethod)

The .NET object instance on which to call the specified method

The method to call.

lvParm1 - lvParm10
Up to 10 parameters that can be passed to the method.


When making many callbacks, there are two ways you can pass your AsyncCallback object to this method:

  • Single shared Instance
    Using a single instance is more memory efficient as it uses a single reference to receive all callbacks. Use this if you don't care about state for the request and you are only interested in the actual result value without any previous association.

  • New instance for each callback
    Using a new instance for each callback allows you to attach state to the request being performed so you can trace the origin back to its source when the callback returns. To attach state you can add properties to the callback object that identify the request when you start the async method call which can then be picked up when the call returns. You can assign a pk, or a timestamp or whatever else you need to track across the async method call. IOW, you use the the event object as a store for some state data that you later need to reference.

Multi-threading Callbacks

Callbacks are fired from another thread and are essentially injected into the FoxPro execution pipeline and fire in the middle of existing code execution. This means don't make assumptions about the state of the environment when your code is called other than what you are directly accessing in your callback method and object. There are no guarantees about what's open and in scope when your callback method is fired.

Don't run a lot of code in these methods and most importantly don't change any external state that might affect the code that's being interrupted, as calling code may depend on things being set a certain way. IOW, don't change the workarea or close tables, or release objects etc. If you do run code and make environment changes, make absolutely sure you clean up and reset the environment exactly as when the call was initiated or you may cause crazy errors in the code that was interrupted by the callback.


DO wwUtils 			&& Demo only
DO wwDotnetBridge	&& Load dependencies

LOCAL loBridge as wwDotnetBridge
loBridge = GetwwDotnetBridge()

*** Create a built-in .NET class
loHttp = loBridge.CreateInstance("System.Net.WebClient")

*** Create a callback object - object has to be 'global'
*** so it's still around when the callback returns
*** Use Public or attach to long lived object like main form or _Screen
PUBLIC loCallback
loCallBack = CREATEOBJECT("HttpCallback")

*** Make the async call - returns immediately
*** Method returns a byte[] array
loBridge.InvokeMethodAsync(loCallback, loHttp, ;

? "Download has started... running in background."


*** Callback class - AsyncCallbackEvents is Optional
DEFINE CLASS HttpCallback as AsyncCallbackEvents

*  OnCompleted
FUNCTION OnCompleted(lvResult, lcMethod)

? "Http Call completed"
? "Received: " + TRANS(LEN(lvResult),"999,999,999")

*** Write to file to temp folder
STRTOFILE(lvResult,ADDBS(SYS(2023)) + "HelpBuilderSetup.exe")

	*** Open the Zip file
	DO wwutils
	GoUrl(ADDBS(SYS(2023)) + "HelpBuilderSetup.exe")


*  OnError
FUNCTION OnError(lcErrorMessage, loException, lcMethod)
? lcErrorMessage


See also:

Class wwDotNetBridge | wwDotNetBridge::InvokeStaticMethodAsync

© West Wind Technologies, 2019 • Updated: 06/09/18
Comment or report problem with topic