Не приходит полная версия OnTrade

О какой секунде речь - не понятно. Если речь про транзакцию, то после её подачи по номеру происходит поиск записи в таблице ордеров сразу, мгновенно. OnTransReply нужен только для того, чтобы прекратить поиск, если есть ошибка. Еще раз в момент принятия решения Вы просто смотрите на данные. Других данных у Вас нет.

VPM
Понятно, вас с "толку" не сбить .
Но интересно, что вы напишите на следующее.
   Обрабатывая коллбеки и восстанавливая их результат, вы, по сути, повторяете (но в условиях неопределенности) работу которая выполняется в QUIK при формировании его таблиц.
  1. Зачем повторять функциональность которую реализовали разработчики и которая отлажена, скорее всего лучше чем "призрачные" коллбеки (зависящие от кода main), так как это было давно (до появления QLua) и проще контролируется?
  2. Полагаете, что вы квалифицированнее разработчиков?
  3. Вы же вроде согласны с принципом "меньше дергаешься - реже падаешь". Вам нечем заняться и хочется поразвлечься с коллбеками?

TGB, Я не пытаюсь навязать событийную модель как единственно верную. Я лишь показываю, что она даёт определённые преимущества в плане гарантий и детерминизма, которые могут быть критичны для сложных систем.

Ваш подход проще и для многих задач достаточен. Выбор зависит от требований к надёжности и готовности платить за сложность.

Если есть конкретные проблемы (например, потеря OnTrade), событийная модель может их решить элегантнее, чем простое увеличение таймаутов. Но если текущая система вас устраивает — нет смысла её усложнять.

Все никак не могу понять о каких таймаутах речь и как потерянное событие решается без прямого обращения к данным. Если у вас есть датчик, то только его опрос даст данные, сам он их не пришлет - это простая железка.

  Это заклинания .   Вы думаете, что они работают?

А что тут комментировать, ЧУШЬ полная! Да и обсуждение совершенно о другом.

  Это ваше добровольное признание :
   На всякий случай ссылка: https://forum.quik.ru/messages/forum10/message78413/topic9090/#message78413

   Если вы не понимаете то, что написано вами, то бесполезно вам что то объяснять. Все равно не поймете.

Ок. Предположим, что скрипт пишется корректно, и в колбеках только быстрое обновление информации, передача полученной информации в поток main.

Это предположение, а не факт. А также не отвечает на вопрос, что делать с пропусками, если блока чтения данных напрямую не предусмотрено.

Учитывать для чего? Если Вы не выполняете код в колбеке, а, как минимум, транзакции отправлять точно не стоит, то чтобы выполнить какое-то действие вы должны вернуться в mian. А значит эта задержка, какая бы она не была, есть постоянная для алгоритма.

Это просто субъективное соображение.



Ок. Пусть есть колбек для таблицы ордеров. Вы его обработали, что-то сделали с информацией. Можно, конечно, даже провести какие-то расчеты в колбеке, но тогда уже стоит учитывать, что данное решение будет плохо масштабироваться, на, скажем, 100 инструментов в одном скрипте. Рекомендация от разработчиков проста - взяли данные в колбеке и передали в main, и уже там с ней работает. И здесь возникает вопрос: если перед принятием решения необходимо иметь актуальную информацию и это мы делаем в main, то что мешает прямо перед принятием решения посмотреть на данные?

Если же колбек используется просто как светофор, то эту модель я как раз могу понять. У нас есть некий метод получения состояния портфеля или другой информации зависящей от сделок, установленных ордеров и т.д. И чтобы постоянно не опрашивать его, можно колбек использовать как сигнал для обновления. Сами данные все равно будет опрошены в main, но уже не постоянно, а по сигналу.

Еще один пример для колбека OnQuote. Я очень часто вижу как внутри этого колбека читают стакан и разбирают данные. И возникает вопрос - а точно понимают что делают?
Пришел колбек, что данные в стакане изменились. Хорошо. Для чего нам эта информация? Если необходимо фиксировать все изменения в потоке времени, а потом их анализировать, то да, другого выхода нет, необходимо читать и разбирать. А если данные стакана потребуются уже только в main, когда дойдем до некого метода где требуется информация о текущем состоянии, то прямо там и надо его прочитать один раз, если был сигнал от колбека. Т.е. сам колбек - это сигнал, что надо данные обновить. Пока дойдём до чтения в main, этот стакан изменится десятки раз. И все изменения кроме последнего - бесполезные.

Лазить в таблицы вместо колбеков имеет смысл ,например, для получения текущих значений счета или размера позиции.
Но даже и в этом случае колбек  может быть полезен.  

Вообще-то, так как роботы есть разные, то целесообразность использования событий(колбеков)  тоже разная.
----------------------
Поэтому сделал обработку для всех событий, а применяю в конкретном роботе то, что имеет смысл "здесь и сейчас".
--------------------
Сейчас у меня все очень оптимально.
Все события обрабатывает один скрипт Он же выставляет и снимает заявки.
Остальные скрипты и приложения занимаются прогнозированием момента изменения позиции по конкретному инструменту
Скрипт(приложение) на инструмент или класс.

И когда она решит это вызвать? Когда цена уже пройдет две планки? Т.е. эту фразу я воспринимаю так: ориентируемся на колбек. Если он не пришел, каким-то образом, скорее всего с некой периодичностью читаем данные и сверяем. Т.е. данные подтверждаются с неким интервалом, возможно даже не таким и маленьким. Да, если считать, что колбек с вероятностью 99.99999 приходит, то можно предложить взять такой риск. Но я уже давно понял, что достаточно одного события с 10 сигма, чтобы потом очень сильно пожалеть. Тем более, что если скрипт не только для себя.

В моей текущей реализации системы, это модуль  Watchdog, задача которого обеспечить непрерывный контроль в реальном времени. Он утверждает: "Прямо сейчас состояние допустимо".
И пусть цена идет куда угодно, пока состояние ни восстановлено, так как принимать решение все равно нельзя. Собственно это и есть механизм защиты от 10 сигма.

Чёт я такого не припоминаю, можно ссылку на обсуждение данной проблемы?

Я не об этом спросил.
Вы утверждаете
Я и спросил были ли сообщения от пользователей об этих случаях, когда данные есть, а колбэка не было?