In an asynchronous runtime environment, one of the challenges is that variables and data can go out of scope before a separate task is completed or a response comes back. This is especially evident when writing client-server software. A server that is under heavy payload might not get around to your request for many seconds, a proverbial eternity in computing terms. By the time the response returns, your program has moved on, and there is no way to determine the circumstance where the original request was made.


If you have a web-application and the user clicks 10 different buttons - you will eventually receive 10 responses. But how exactly will you tell response #1 from response #7?

The variables that existed when the button was clicked have been released, so there is no way to distinguish how each response should be interpreted.


In the world of JavaScript this problem has been addressed in multiple ways over the years, but one of the most effective ways to deal with the issue, is simply to include a piece of data in your call, that can help you translate and identify what the response is when it comes back.


procedure TForm1.DoSomething(TagValue: variant; CB: TSomeCallback);

begin

 // do your work here

 ..

 ..

 // All done, now return the tagvalue to the invoker

 if assigned(CB) then

   CB(TagValue);

end;


To be blunt, you literally send a piece of data through the call - and that piece of data is delivered back to you when the response returns (or more correct: when the process calls you back with the result).

This piece of data is simply called a TagValue. A value that is tagged onto the call or request.