And have it send events and callback. Two demo .PRG files presented.

sg12, боюсь, ты сам не пробовал воспользоваться этой идеей. А у меня при переносе метода WorkIt из класса Worker на уровень выше в AsyncServer этот метод не хочет вовремя остановиться и выдаёт сообщение, что куда-то пропал его любимый элемент THIS.BackCaller_o.
Ребята, вы как-нибудь поответственнее к своим словам. Ведь вы все - профессионалы.
Но если уж о чём я жалею, это важный момент реализации DCOM-сервера, который надо бы отразить даже в демонстрашке. Чтоб сервер не захватывал всю память, надо непременно в его метод Init вставить SYS(3050,1,10000000) - ограничить аппетит 10 мегобайтами.

sg12, хоть твоё предложение и невпопад, но спасибо, что моя попытка его реализации натолкнула меня на важную подробность. Если метод WorkIt в верхнем классе AsyncServer, то после выполнения AsyncServer.Destroy управление переходит к неуспевшему остановиться AsyncServer.WorkIt. Это чревато неприятностями, даже если из AsyncServer.Destroy запущено аккуратное закрытие выполняемого задания. Чтобы избежать возобновления работы AsyncServer.WorkIt надо или вставлять в него специально для этого случая какое-то ON ERROR, или просто держать этот метод в отдельном классе, как у меня и сделано. Ведь ON ERROR в WorkIt для персечения его работы это, во-первыхи, извращение, а во-вторых - всё равно всё равно WorkIt останавливается не вовремя.
А если после AsyncServer.Destroy запустится Worker.Destroy, то Worker.WorkIt уже не включится. - Хотя, это я сейчас проверю.

sg12, вместо того, чтоб давать объяснения для дураков, как им ноги переставлять, лучше пришли работающий код.

Докладываю факты. В конец AsyncServer.Destroy, Worker.Destroy, Starter.Timer и Worker.WorkIt вставлена выдача в текстовый файл времени выхода из этих методов.
18:07:50 WorkIt Fini -- Первая интерактивная остановка
18:07:50 Starter.Timer
18:08:13 AsyncServer.Destroy -- Обнуление объекта сервера в приложении клиента
18:08:13 WorkIt Fini
18:08:13 Starter.Timer
18:08:13 Worker.Destroy
Если же в AsyncServer.Destroy не сбрасывать флаг Worker.StopFlag_l, то из-за того, что предотвратить возврат управления в прерванный Worker.WorkIt из AsyncServer.Destroy невозможно, то не завершённый Worker.WorkIt не даст закрыться COM-серверу - он продолжит занимать память без использования ЦПУ.
А вот если поместить WorkIt в AsyncServer, то нормальное завершение этого метода по сбросу флага StopFlag_l уже невозможно, т.к. после выполнения AsyncServer.Destroy этот класс уже не сохраняет условий для выполнения других своих методов.
Ещё раз спасибо коллеге sg12, что он обратил моё внимание на этот скользкий момент прерывания работы запущенного метода. В классе Worker обязательно должен быть метод Destroy!
Но простите меня, выставлять исправленный код я уж не буду.

Пожалуй, я погорячился. Ведь "насильственно" прекратить работу метода WorkIt у нас нет фоксовских средств. Т.е. если WorkIt усмотрит через какое-то время после срабатывания AsyncServer.Destroy флаг экстренной остановки StopIt, то этот флаг и послужит ему сигналом аккуратного заметания следов незаконченной работы. И метод Worker.Destroy для этой цели не нужен.
А чтоб мой демонстратор был пореалистичнее, в нём надо дать возможность штатного завершения методу WorkIt - например, по интервалу времени.
Пожалуй, повторю выкладку скорректированной редакции.

sg12, тебе "непонятно" (10.03.2013 17:10, 14031939), а ты бы подумал, почему первые два запуска перемещённый по твоему рецепту метод AsyncServer.WorkIt работает без запинки, а после срабатывания AsyncServer.Destroy - уже не может. Как же, по-твоему, этот метод работал "до того", если я, по твоему предположению, понаделал каких-то ошибок в реализации твоего "мудрого" совета?
Стыдно лепить в ленту нафантазированные предположения!

Dima T, а ведь это ты гонишь какое-то духовидство.
Запускаем программу TestTimer.PRG и смотрим её выдачу TestTimer.LOG.
Реальными фактами твои предположения не подтверждаются, значит - нафантазировал. Ай-я-яй.
TestTimer.PRG
SET TEXTMERGE ON
SET TEXTMERGE TO TestTimer.LOG
Timer_lo = NEWOBJECT ('MyTimer')
GETFILE() && We'll have a walk, while MyTimer's working
\ <<TIME()>> Basta
SET TEXTMERGE TO
SET TEXTMERGE OFF
*****************************
DEFINE CLASS MyTimer AS Timer
Interval = 2000
Enabled = .T.
PROCEDURE Timer
\ <<TIME()>> <<PROGRAM()>>
THIS.Interval = 0
ENDPROC && MyTimer.Timer
ENDDEFINE && MyTimer

TestTimer.LOG
19:21:17 MYTIMER.TIMER
19:21:32 Basta

Dima T, Для большей наглядности и доказательности. Нет такой стандартной ошибки, есть у твоя стандартная выдумка - не лезть за словом ни в карман, ни в эксперимент. Духовидство, или проще, застарелые предрассудки
TestTimer.PRG
SET TEXTMERGE ON
SET TEXTMERGE TO TestTimer.LOG
\ <<TIME()>> Starting
Timer_lo = NEWOBJECT ('MyTimer')
GETFILE() && We'll have a walk, while MyTimer's working
\ <<TIME()>> Basta
SET TEXTMERGE TO
SET TEXTMERGE OFF
*****************************
DEFINE CLASS MyTimer AS Timer
Interval = 2000
Enabled = .T.
PROCEDURE Timer
\ <<TIME()>> <<PROGRAM()>>
THIS.Interval = 0
m.t0 = SECONDS()
DO WHILE SECONDS() < m.t0 + 10
ENDDO
\ <<TIME()>> After 10 seconds
ENDPROC && MyTimer.Timer
ENDDEFINE && MyTimer

TestTimer.LOG
19:36:18 Starting
19:36:20 MYTIMER.TIMER
19:36:30 After 10 seconds
19:36:44 Basta

Итак, в эксперименте родилось новое знание, недоступное ранее без влезания в "асинхронность".
После срабатывания метода Class.Destory никакому другому методу на этаже этого класса уже работать не позволено.
А вот для Member-классов, такая возможность предоставлена - их методы Destroy вызываются последовательно по цепочке вложенности Member-ship.

Dima T, этот пример надуманный, к делу не относится. Значение Interval = 1 - одна милли-секунда - это погрешность срабатывания таймера. Использовать такие значения - просто техническая неграмотность.
В моём примере с AsyncServer значение Starter.Interval = 1000 - 1 cек, реалистично.
Так твои фокусы тебя не спасают, и sg12 - тоже.