Nikolay (Все сообщения пользователя)

Зря Вы это написали, т.к. в таком случае документацию необходимо обновлять и точно указывать для каких методов не гарантируется корректная работа при отсутствии соединения. Более того, если в процессе работы происходит разрыв соединения и в этот момент скрипт выполняет метод, который может привести к "зависанию" терминала, то это уже совсем не корректно, а вполне себе ошибка. И чтобы её избежать необходимо понимать какие методы необходимо обрамлять предварительной проверкой на наличие соединения.

Проверяйте что возвращает метод sendTransaction. Если не пустая строка, то даст описание ошибки.

Формат вызова:

STRING result sendTransaction(TABLE transaction)

Параметры:

• result – строка, содержащая текст ошибки, если она случилась при обработке транзакции;
  
• transaction – таблица с параметрами транзакции.
  

Если искателю require задан путь к модулю и модуль имеет открытый код или скомпилирован с той же версией что и qlua, то он будет подключен.

А будет ли он работать уже зависит от того как он написан, какие у него зависимости. В общем случае - будет.

Надёжных в API нет. В этом и проблема. Искать по форуму - обсуждения были и 10 лет назад.

Это так часто уже обсуждалось на форуме. Необходимо организовать процедуру ожидания загрузки данных с сервера брокера. К сожалению, разработчики считают, что это не проблема, поэтому никаких конкретных методов для этого нет.

Что можно сделать:
- Сравнивать время последнего полученного пакета и время сервера, чтобы расхождение укладывалось в допустимую дельту.
- Также можно сравнивать время сервера и локальное время, но оно должно быть точным.
- Если в процессе работы были установлены ордера, то необходимо запоминать число записей в таблицах и после восстановления связи ожидать пока там не появится необходимое число записей, или хотя бы отличное от нуля.
- Ожидать загрузки таблиц денежных лимитов и лимитов срочной секции (если есть)

т.е. процедуры проверки, что в таблицах данные есть, что пакеты данных догнали время сервера.

Кажется, что Вы опять увлекаетесь теорией. Для чего существуют фильтры - для обработки сигналов.

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

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

Потому стали выдумывать разные подходы, искать закономерности. Т.е. гадать, на самом деле. В итоге, можно было бы просто взять карандаш и обвести график некой линией, и выполнять такие же упражнения.
Всё сводится к предположениям: если цена выше, ниже отфильтрованной линии; пересекает линию; две-три отфильтрованные линии пересекаются и т.д. и т.д. И всё это носит вероятностный характер. Что кардинально отличается от того как применяются фильтры и для чего они были придуманы изначально.

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

Это не значит, что фильтры и анализ прошлого совсем бесполезны. У рынка, т.е. у участников, тоже есть инерция. Поэтому какое-то время можно строить предположения на базе прошлого. Но приходится постоянно изменять параметры, проверять, контролировать. В текущих реалиях это вполне можно отдать какому-то агенту, т.к. это очень муторная, скучная работа.

Т.о. нет идеального фильтра. Они примерно одинаковы, решают одну задачу - нарисовать карандашом линию. Свечи - это тоже, вполне себе, фильтр. А т.к. многие поколения участников проходят один и тот же путь, то 200 EMA становится чем-то магическим, от которой цена отскакивает. И действительно может. Почему, потому что работает обратная связь. Т.е. хвост виляет собакой.

Мне сложно комментировать это, т.к. это просто эмоции. Хотя вполне себе можно напомнить о penny-stock, которые вполне себе шортят на выносах, "наплевав на всякую статистику", т.к. это банальный pump.

Потому что фильтр - это алгоритм для существующего сигнала. Фурье - это тоже фильтр. И проблемы у него такие же как у фильтра. Т.е. есть сигнал. Задача привести его к какому-то виду, выделить составляющие.
Применяем фильтр, радуемся.

Если же задача - сказать, а сколько будет завтра? То уже всё сложнее, т.к. фильтр может сказать фазу (частоту), амплитуду, но и все. Можете пробовать продолжать сигнал на шаг вперед, никто не мешает. Но дело-то в том, что сигнал может взять и развернуться, просто так, наплевав на вычисленную фазу. Неправильный сигнал... Если мы обрабатываем физические сигналы, то там фильтрация отлично работает. Если же у нас не сигнал, а хаотичные кнопко-нажатия участников рынка, то здесь уже поведенческие модели лучше будут работать.

Мои применения методики приводили к тому, что можно пробовать предсказывать на отрезке 5-10% от окна вперед, не больше. Делать далеко-идущие выводы - точно нет.

Банальная ансамблевая регрессия лучше работает, без всякого Фурье. Но и его можно оставить, просто чтобы оценить первую-вторую гармоники.

Это банальный подход. Регрессия чрез фильтр Калмана, да даже гармоническая регрессия уже более стабильны.

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

Т.к. ценовые ряды стохастические, без явной автокорреляции, то и выход за канал, какой бы широкий он ни был (хоть 5 сигма) - не является чем-то сверхъестественным. А скорее вполне закономерным явлением.

Этим методикам уже столько лет. Детрендинг - это построение регрессионной модели ряда и получение остатка.
Циклы - это чаще всего преобразование Фурье, для получения периодических составляющих.

Если используете Питон, то можно это сделать достаточно просто.
Я для Lua писал библиотеку на С, проводящую такого рода операции.

Если же говорить о Квантах, то советую углубится в стохастические процессы и цепи Маркова.

Регистрируйте.

Если он будет вызван после, то этот колбек бесполезен.

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

Есть колбек OnClose. Казалось бы, он должен помочь понять, что терминал остановлен. Но явно что-то пошло не так.

Берем простой скрипт. Закрываем терминал через "крестик".

Ожидание - 1. OnClose, сбрасываем флаг. 2. выходим из main.

Код

local sleep  = _G.sleep local isRun  = true local AddLabel          = _G.AddLabel local GetLabelParams    = _G.GetLabelParams local logFile local function log_tostring(...)     local n = select('#', ...)     if n == 1 then     return tostring(select(1, ...))     end     local t = {}     for i = 1, n do     t[#t + 1] = tostring((select(i, ...)))     end     return table.concat(t, " ") end local function log(...)     if logFile==nil then return end     logFile:write(tostring(os.date("%c",os.time())).." "..log_tostring(...).."\n");     logFile:flush(); end function _G.OnStop()     isRun = false     log("Script Stoped")     if logFile then logFile:close() end end function _G.OnClose()     isRun = false     log("Script OnClose")     if logFile then logFile:close() end end function _G.main()     logFile = io.open(_G.getScriptPath().."\\labels_test.txt", "w")     local t_id = _G.AllocTable()     _G.AddColumn(t_id, 1, 'test', true, _G.QTABLE_STRING_TYPE, 20)     _G.CreateWindow(t_id)     local tag = 'virt_test'     local label_params = {}     label_params.YVALUE = 324     label_params.TEXT = 'TEST    |||||||||||||||||||||||||||||||||||||||||||||'     label_params.HINT = 'Еще текст'     label_params.DATE = 20260512     label_params.TIME = 135000     label_params.FONT_FACE_NAME = 'Arial'     label_params.ALIGNMENT = 'RIGHT'     label_params.FONT_HEIGHT    = 10     label_params.TRANSPARENT_BACKGROUND    = 1     local data = {price = 324}     local l_id = AddLabel(tag, label_params)     sleep(1000)          while isRun do         local i = 1         while isRun and i < 10 do             label_params = GetLabelParams(tag, l_id)             if label_params then                 data.price = tonumber(label_params.yvalue) or 0             end             log(os.clock(), i, 'IsWindowClosed', tostring(_G.IsWindowClosed(t_id)), 'label_params', tostring(label_params), tag, 'l_id', l_id, tostring(data.price))             i = i+1         end         log(os.clock(), 'sleep')         sleep(100)     end end

Выводит метку на график, создаём окно. Далее выводим данные метки с графика и закрыто ли окно. Смотрим лог:

Tue May 12 15:07:59 2026 30.832 sleep
Tue May 12 15:07:59 2026 30.946 1 IsWindowClosed false label_params table: 00000205F30168A0 virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 30.947 2 IsWindowClosed false label_params table: 00000205F3016BA0 virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 30.947 3 IsWindowClosed false label_params table: 00000205F3017BA0 virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 30.947 4 IsWindowClosed false label_params table: 00000205F3017160 virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 30.947 5 IsWindowClosed false label_params table: 00000205F3018020 virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 30.947 6 IsWindowClosed false label_params table: 00000205F30171A0 virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 30.947 7 IsWindowClosed false label_params table: 00000205F30171E0 virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 30.947 8 IsWindowClosed false label_params table: 00000205F3017F20 virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 30.948 9 IsWindowClosed false label_params table: 00000205F3017A60 virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 30.948 sleep

Окно ещё не уничтожено, но графика уже нет и данные метки не получены.
Tue May 12 15:07:59 2026 31.061 1 IsWindowClosed false label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 31.061 2 IsWindowClosed false label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 31.061 3 IsWindowClosed false label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 31.061 4 IsWindowClosed false label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 31.061 5 IsWindowClosed false label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 31.061 6 IsWindowClosed false label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 31.061 7 IsWindowClosed false label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 31.061 8 IsWindowClosed false label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 31.061 9 IsWindowClosed false label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:07:59 2026 31.061 sleep

А здесь уже и окна нет
Tue May 12 15:08:00 2026 31.173 1 IsWindowClosed true label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:08:00 2026 31.173 2 IsWindowClosed true label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:08:00 2026 31.173 3 IsWindowClosed true label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:08:00 2026 31.173 4 IsWindowClosed true label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:08:00 2026 31.173 5 IsWindowClosed true label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:08:00 2026 31.173 6 IsWindowClosed true label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:08:00 2026 31.173 7 IsWindowClosed true label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:08:00 2026 31.173 8 IsWindowClosed true label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:08:00 2026 31.173 9 IsWindowClosed true label_params nil virt_test l_id 13.0 324.0
Tue May 12 15:08:00 2026 31.173 sleep

Только сейчас OnClose
Tue May 12 15:08:00 2026 Script OnClose

Сама по себе схема, вроде, корректна, если бы OnClose мог выполнится параллельно, не обращая внимания на работу main. Но это не так. В итоге OnClose вызывается когда уже уничтожено окно скрипта и нет графика. Т.е. некоторое время (а точнее пока не вызовется C функция) у нас есть подвешенное состояние - мы не знаем окно, график закрыты пользователем или нет.
В итоге, если в это время считаем метку, а её нет, можем принять не верное решение. Аналогично и по окну скрипта.

Что хотелось бы: вместо колбека иметь глобальный флаг, состояние или иное, сигнализирующее, что терминал закрывается. При этом он должен быть установлен быстро, перед уничтожением объектов терминала. Аналогия из электротехники - логическое 1 или 0 на контакте. Если 0, то уже всё, логика работы совершенно иная.

Текущая же реализация может работать, если бы OnClose вызывался до уничтожения объектов.

Да. Но не забывайте про округление до "красивых чисел" для шага страйка. Впрочем, как писал, в теории ничто не мешает ему быть дробным. Здесь уже, видимо, как сама биржа решает. С целыми числами банально проще работать и могут решить, что не стоит и усложнять.

Исходя из спецификации кодировки страйка, там число = цена БА * Лотность.

Для опционов на фьючерсные контракты в поле "страйк" указывается котировка базового актива (котировка фьючерсного контракта). В свою очередь, котировка фьючерсного контракта – это произведение цены базового актива фьючерса на размер лота фьючерса.

Лотность обычно приведёт его к целому числу. Но в теории, может быть и дробное. У нас на бирже таких вроде нет, т.к. лотность перекрывает точность цены. Шаг же страйка имеет ещё округление в формуле, т.е. тоже не даёт дробных.

Вопрос был о другом: Как программно узнать текущую цену (премию) опциона?

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

Если задача просто узнать сколько можно купить продать по текущей цене, то для этого есть методы в QLUA: CalcBuySell, getBuySellInfoEx (см. документацию по ним).

Если же задача найти неэффективности, то уже необходимо самому считать цену на базе своей модели. Например, ММВБ считает по формуле Блэка-Шоулза. Поэтому рассчитав по IV свою цену можно будет увидеть неэффективность и принять решение. Но это для покупателей опционов.

Продавцы же платят ГО. И здесь уже всё сложнее - расчет гарантийного обеспечения (ГО) по опционам осуществляется по методике, аналогичной системе SPAN (Standard Portfolio Analysis of Risk)

Спросим любой чат:

Главный принцип: ГО считается не изолированно для каждого контракта, а для всего портфеля (с учетом взаимной компенсации рисков позиций по одному базовому активу). Однако базовая аналитическая формула для отдельной позиции (проданного опциона) строится на сценарном подходе.

Для начала важно отметить: по купленным опционам ГО не списывается (уплачивается только премия). ГО взимается только с продавцов опционов.

Ниже приведена логика и аналитические формулы расчета.

1. Концептуальная формула (для одной короткой позиции)

Математически гарантийное обеспечение по короткой позиции по опциону равно максимальной стоимости этого опциона в стрессовых сценариях:

ГОshort​=max(V1​,V2​,...,Vn​)   где Vi​  — теоретическая стоимость опциона в i -м сценарии риска.

На практике Клиринговый центр (КЦ) Мосбиржи разделяет это ГО на две составляющие: Премиальную маржу (ПМ) и Рисковую маржу (РМ).  

Формула выглядит так:  

ГО=ПМ+РМ  

• Премиальная маржа (ПМ) — это текущая рыночная (или теоретическая) стоимость опциона. То, что вы уже должны рынку, если бы позицию нужно было закрыть прямо сейчас. ПМ=V0​  (где V0​  — текущая стоимость опциона).
  
• Рисковая маржа (РМ) — это резерв на случай неблагоприятного изменения рынка до следующего клиринга. РМ=max(Vi​)−V0​   Если подставить это в формулу, получим:  ГО=V0​+(max(Vi​)−V0​)=max(Vi​)
  

2. Как строятся сценарии (Vi​ )?

Чтобы рассчитать

max(Vi​) , Мосбиржа генерирует сценарии изменения цены и волатильности базового актива (фьючерса).  

Для этого рассчитываются интервалы риска:

1. Интервал риска по цене (IR) — насколько может упасть/вырасти фьючерс. IR=F0​×RF​      где F0​  — текущая цена фьючерса, RF​  — ставка риска по фьючерсу (зависит от актива, например, 8-12% для валют, больше для акций).
   
2. Интервал риска по волатильности (IV) — насколько может измениться подразумеваемая волатильность. IV=σ0​×RV​      где σ0​  — текущая волатильность, RV​  — ставка риска по волатильности.
   

Затем КЦ Мосбиржи моделирует до 16 (и более) сценариев, сдвигая цену фьючерса на доли интервала

IR  (например, +1/3IR , −2/3IR , +IR , −IR ) и волатильность на +IV , −IV  или 0 . В каждом сценарии по формуле Блэка-Шоулза (модифицированной для фьючерсов) считается новая цена опциона Vi​ .

3. Формула для портфеля (Базовое ГО)

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

Для портфеля рассчитывается Базовое гарантийное обеспечение (БГО):

БГО=max(L1​,L2​,...,Ln​)   где Li​  — совокупный убыток всего портфеля по одному базовому активу в i -м сценарии.

Убыток в сценарии считается как изменение стоимости портфеля:  

Li​=∑k​(Vi,k​−V0,k​)×qk​  где qk​  — количество k -го инструмента (со знаком: минус для коротких, плюс для длинных).

Благодаря этому подходу риски взаимно зачитываются. Например, если вы продали опцион Call (большой риск роста), но купили фьючерс (даст прибыль при росте), ГО портфеля будет значительно меньше, чем ГО просто по проданному Call.

4. Итоговое ГО с учетом спредов

После расчета Базового ГО, КЦ применяет скидки за межтоварные спреды (если у вас позиции по коррелируемым активам, например, фьючерсы на акции Сбера и ВТБ) и минимальное ГО.

Итоговая формула:  

ГОитог​=БГО−Скидкаспреды​   При этом действует жесткое ограничение: ГО не может быть меньше минимальной маржи (обычно это половина от Базового ГО или фиксированная сумма в зависимости от типа спреда).

Резюме: где посмотреть точные параметры?

Аналитически посчитать ГО дома на коленке сложно, так как постоянно меняются:

1. Ставки риска RF​  и RV​  (КЦ меняет их при изменении волатильности на рынке).
   
2. Количество сценариев.
   
3. Правила взаимозачета для сложных спредов (стрэддлы, конверсии, реверсы).
   

Поэтому для точного расчета используют API Московской биржи (соответствующие таблицы клиринга) или встроенные калькуляторы в торговых терминалах (QUIK, T-Invest), которые отправляют запрос на сервер Мосбиржи и получают точное значение ГО по вашей виртуальной позиции.

Он менее рискован чем линейные фьючерсы. А если не совершать продажи, так вообще безопасней некуда. Откуда взялась эта байка - не понятно.

Да. Если алгоритм формирования кода корректный, то и проверять не обязательно. Но это просто хорошая практика проверять входные данные в функции.

Он определяется биржей https://fs.moex.com/f/4606/optimum-strike-step.pdf

Вся информация есть на сайте биржи.

Т.к. опцион содержит цену страйка в своем коде, т.е. это и есть страйк (https://www.moex.com/s205), то никак. Тем более, что в теории цена базового актива ничем не ограничена, раз уже и отрицательные цены есть. Смотрите пример спецификации кода для нефти.

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

Не очень понятен вопрос, т.к. это просто инструмент, такой же, по сути, как RIM6 SPBFUT. Методы получения данных те же, метода работы с заявками тоже.
Страйк это не какой-то параметр, а данные инструмента, т.е. каждый страйк это отдельный инструмент. Поэтому необходимо просто посмотреть спецификацию формирования кода опциона и выбирать необходимые.
Тот же RIM6 - это код инструмента. RI - контракт на фьючерс РТС. M - месяц экспирации (июнь). 6 - год. С опционами также, но просто методика формирования кода более сложная.

Он и опрашивается, через запомненный индекс записи в таблице. Когда ордер найден в таблице, то повторно его иска не надо, просто получить запись в таблице с свежими данными.

Да. Датчик температуры ничего не скажет об её изменении. Спросите - скажет.

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

А колбеки я использую если данные из Квика обрабатываются через межсетевое взаимодействие. Например тот же торговый алгоритм, написанный на GO.
Но если внутри терминала, где данные есть и доступны всегда, то колбек (именно в этой реализации что есть в Квике) не является единственным и идеальным решением.

С учетом того, что торги на бирже в первую очередь необходимы "финансовым институтам", т.е. крупным участникам, то и лоты сделаны для них. Физические лица, как обычно, не являются значимыми.

Если просто спросить, то вот ответ:


[*]Первые акции (начало XVII века): В 1602 году Голландская Ост-Индская компания  выпустила первые в мире акции. В то время сделки были штучными, а  понятие фиксированного «лота» в современном понимании (пакет из 10, 100  или 1000 бумаг) еще не было жестко стандартизировано.
[*]Стандартизация (XIX век):  С развитием телеграфной связи и ростом оборотов на таких площадках, как  Нью-Йоркская фондовая биржа (NYSE), возникла необходимость в ускорении  расчетов. Тогда появился «круглый лот» (round lot), традиционно равный 100 акциям. Это упрощало учет и отчетность.

Цена всегда за акцию. Лот - это минимально возможное число единиц для покупки на основной секции. Т.е. можно купить 1 лот, где 10 акций. Значит необходимо заплатить цена*10.
Есть ещё специальная секция для торговли неполными лотами, т.е. можно совершать сделки не лотами, а единицами акций.

Таблицу обезличенных сделок, как разбор стакана, делать только через main. Через колбеки - это плохая затея.

Если же говорить о нагрузке, то вызов getNumberOf("trades") хоть раз в 2 млс - это не то, о чём стоит говорить. Стоит думать о том, какой цикл выполнения функции main. Если это 100 млс, для примера, то ручной разбор сделок будет неотличим от колбека, если говорить о временной составляющей. Даже скорее быстрее, что я показал в одной из веток при анализе одного брокера.

Если же цикл main секунда и более, то уже стоит думать о сокращении этого времени, т.к. колбек хоть может и придёт, но действия по этому колбеку всё равно будет в main, а он медленный.

Так реализация банальна. Запоминаете число записей в таблице при прошлом запросе. При новом проверяете число записей и если оно изменилось, значит есть новая сделка. А дальше уже можете просто перебрать с прошлого индекса до нового или вызвать поиск тоже с прошлого индекса. Ничего необычного. Может даже назначит функцию колбек на новую запись и будет вам свой колбек, а не системный. Причем его никогда не пропустите, т.к. при старте скрипта опросите таблицу.

Можно и так сказать. Вы можете просто ждать колбека. А можете постоянно опрашивать таблицу. Именно, что постоянно. Естественно через проверку числа записей в таблице как триггер.
На вопрос - это же накладно. Ответ - большую часть времени скрипт ничего не делает, так что проверить число записей в таблице - это можно сказать что ничего.

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

Меня смущает этот вопрос. Really?

Мы же про сделки говорим. Вы получите все сделки ордера. Это и есть ВСЯ история сделок. Сделка - это законченное, неделимое целое с точки зрения таблицы Квик. Чем будет отличаться полученное если это через колбеки или через таблицу сделок? Или здесь вопрос в времени запроса? Хотя и оно будет одинаковым до долей. Содержимое-то не изменится.

Что же касается остального - все подходы по учету дублей такие же. Сделку прочитали - записали, то зачем её ещё раз учитывать, если второй раз читаете? Точно также как с колбеком - пришел раз, второй уже не учитываешь.

Частичные исполнения в динамике - да также. Увидел, что баланс изменился - посмотри сделки.

Мы здесь разбираем пример работы с ордерами. Но сделки, на самом деле, учитываются независимо, через накопление в буфер. Сделка необходима для расчета своей позиции скрипта, независимой от другого скрипта.
Поэтому сделки контролируются просто постоянно. А уже при проверке ордера мы обращаемся к источнику сделок. Если же позиция контролируется не через сделки, то да, источник - сама таблица сделок.

Да, у брокера. Причем у большинства это не 50, а 30.

Она ломается, т.к. есть попытка организовать алгоритм, основанный на последовательности. Но т.к. порядок прихода колбеков, да и в целом приход данных с сервера брокера - не имеет определенного порядка.

Да, сделки могут прийти первыми, до ордера. И что это ломает.

Вы просто выполняете свой алгоритм:

Отправили транзакцию.
Ждем появления ордера по номеру транзакции. Хоть по колбеку, хоть сканируя появления записи в таблице ордеров.
Получили ордер. Смотрим на его состояние. И здесь опять не важно как: колбеком или чтением данных с "датчика".
Если состояние изменилось, то переходите к шагу для текущего состояния.
Исполнен - смотрим на сделки. Можно в лоб прочитать таблицу сделок через SearchItems (номер ордера же уже есть). А можно накапливать буфер прошедших сделок, и уже читать из этого буфера. Т.о. не важно пришла ли сделка первой или второй.
Не активен - проверяем какой баланс, и если отличается от количества, то еще необходимо получить сделки до снятия.

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

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

Это не так. Это просто попытка сделать как было модно, лет 15 назад. Использовать колбеки или нет - это ваше дело. Сейчас разработчики утверждают, что колбеки гарантированы, и можете их использовать, не думая, что пропустите. Но это не избавляет от необходимости опрашивать таблицы, при старте, очистке таблиц брокером, актуализации состояния и др. Так что в любом случае будет и контур колбеков (если они используются), и контур опроса таблиц. Причем без первого можно работать, а вот без второго - уже никак.

Это не вся информация. Сделки по конкретному ордеру необходимы чтобы:

- узнать время сделок.
- узнать цену и объем сделок

Торговля одним лотом - это замечательно, но совсем не показательно. Также есть ордера "по рынку" и цену исполнения такого ордера Вы не узнаете из самого ордера.

После того как прочитали, что состояние ордера изменилось - просто вызываете поиск сделок по номеру ордера.

Добавлю - вы, конечно, можете зарегистрировать пожелание, но корректная реализация была бы поддержкой HiDPI дисплеев и системных настроек Windows.
А также, наконец, реализовать возможность изменения размеров многих системных окон, типа Lua скрипты, Ввода заявки и т.д.

Можно сказать что понимаем, что разработка началась ещё в 90-х, но в текущих реалиях намного важнее не "темная тема" (на самом деле вредная для глаз), а корректная работа на современном "железе" и современных OS.
Одна надежда, что в будущих версиях Windows наконец уберет поддержку "из коробки" ANSI win1251 кодировку (и заставит устанавливать доп. патч если все же она нужна) и возможно это заставит все же реализовать поддержку UTF8.

Длина комментария ограничена. Сначала проверьте в окне ввода заявки.
Также есть один брокер, который обрезает данное поле и не транслирует далее в OnOrder, OnTrade

Не только очередь, а еще ack флаги. Сама очередь ничего не гарантирует.

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

А потом все эти три ордера прилетают.

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

Так что даже в банальное открытие рынка часто подвисает, т.к. сразу проходит много сделок.

 А что простой ping или tracert говорит?

Это как пришел один и попросил поднять налоги всем на 10%, сделал это через форму подачи заявлений, которая хоть всем и доступна, но предполагает, что её все должны читать. Раз никто не возразил, значит все согласны.

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

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

Попросил именно в таком виде? А спросить у остальных, устраивает это или нет? Многие вопросы касательно форума не решаются, а такое "вырви глаз" - сразу...

Один.

Такая задержка не новость. В марте 2020 были и больше, но там было ясно, что сервер брокера не справляется. В 2022 тоже самое. В 2011, 2014, 2016 - любой год можно назвать.

Готовятся

https://www.moex.com/ru/derivatives/unified-trading-session

Вчера, после выключения электричества на длительное время, один терминал и  скрипт был перезапущен в 14:42:38. При старте найдены запомненные  ордера. Далее брокер начал активно обмениваться сообщениями типа:

OnTransReply  result_msg: Справочник отправлен. status: 3 trans_id: 19 order_num: 0  price: 0 qty: nil account  client_code  firmid nil brokerref

В  итоге сканер сделок по таблице увидел новую сделку от 14:57:01, сканер  состояния ордеров через таблицы увидел изменение состояния ордера на  исполнен в 14:59:31 - две с половиной минуты от сделки.
При этом колбеки OnTrade и OnOrder пришли в 14:59:32, т.е. на секунду позже.

Так что я так и продолжу работать как это делают в системах на "железе", без всяких колбеков.

Этот  брокер всегда отличался особой неспешностью. Запуск терминала в  14:42:38. В 14:43:01 состояние ордера было прочитано как активен. Сделка  в 14:57:01.

В 14:59:30 до сих пор идут транзакции вида : OnTransReply result_msg: Справочник отправлен.

По  факту исполнения ордера была отправлена транзакция, на зеркальный ордер  в 14:59:31. И в итоге за 120 секунд так и не пришел ответ транзакции и  ордер. Т.е. эффект полного отказа сервера брокера. Ответ пришел только в  15:02:41 - три минуты.
Только в 15:02:35 ответы стали приходит за адекватное время - 20 минут после старта.

Можно винить брокера, он резервный и не особо важен, но сам факт такого поведения на 12-ой версии печален.

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

Просто удалить каталог. Можно еще почистить реестр, чтобы не светились ярлыки, но все лежит в каталоге.

Вы неправильно оцениваете клиентов компании ARQA. Это брокеры и проф. участники. Розничные спекулянты - это клиенты брокеров. Их можно послушать, особенно в части найденных ошибок, но точно не в части курса развития разработки.

Если это беспокоит, то работа с колбеками организован некорректно. Приход колбека должен быть не прерыванием, а добавлением события в очередь. Когда завершите всю работу с инициализацией, то разберете колбеки что пришли, если пришли. А порядок инициализации не испортится, если это сделать не в OnInit. Вы же сами его задаете, вызывая последовательно модули. Хотя и здесь, если вдруг потребуется его изменить, придется переписывать код.

Также, как я уже сказал выше, передача модулей по ссылкам выглядит "коряво".

OrderManager.init({ExecutionLedger = ExecutionLedger, Logger = Logger})

Если бы каждый модуль сам подключал библиотеки через require, то и передавать их не придется. Например, какой-то модуль для своей работы требует библиотеку, которая больше нигде не используется. Почему же модель сам не подключит ее и будет работать с ней. Если он один, то скажете: хорошо, тогда там и подключу его через dofile. А если таких модулей два? В итоге Вы вынуждены подключать их в одном месте и передавать как параметры.

Хотя задача решается элементарно:


Где подключать my_module1, my_module2 и в каком порядке - вопрос второй. Но смысл в том, что каждый модуль несет ответственность за свой контекст.

Здесь не так использование dofile, что и заставляет использовать так. Я не вижу все файлы, то проблема dofile в том, что он каждый раз локализует и исполняет файл. Что кардинально отличается от require. Также dofile работает в глобальном контексте, не позволит подключить один и тот же файл один раз в разных модулях, например, тот же модуль логирования. Вы же из-за такой схемы передаете модули как параметры и будет вынуждены так и гонять контекст туда-обратно. Также если метод  utils.safeParam - это оболочка для getParamEx, то в OnInt не стоит его вызывать, это уже не технологический запрос, а логический к данным.

А сам OnInit в таком виде - не нужен. Я меня также его нет, просто вызываю в начале main свой метод on_init, где выполняю технологические операции при старте скрипта.

А теперь представьте, что у вас запускаемый скрипт не содержит main. Т.е. тот файл, что выбирает в Квик - это скрbпт без main. Единственное, что этот скрипт делает - это подключает библиотеки и устанавливает параметры, имеет свой искатель библиотек (если нужно).

А как же это работает? Просто - подключая какую-то библиотеку через require, выполняется тело библиотеки. И в какой-то есть main.
Т.о. этот запускаемый файл и выполняет роль инициализатора скрипта. Почему - это не в OnInit. Ответ прост - это намного гибче, т.к. пока дойдем до выполнения main уже выполнится много кода, инициализирующую среду исполнения. Причем в зависимости от скрипта, инициализация разная, может быть сложная, в может простая. Каждая подключаемая библиотека тоже что-то свое подключает.

Т.о. когда доходим до OnInit, то мы уже имеем инициализированную среду и нам остается только вывести в лог пути к подключенным библиотекам, их версии, параметры. Т.е. мы фиксируем в лог что подключено и какие параметры среды. Если всю работу выше загнать в OnInit, то он будет сложным, плохо контролируемым. Т.е. OnInit - это окончание инициализации, где просто выводим в лог состояние. а не начало инициализации.

Также достаточно просто посмотреть на схему выполнения Lua скрипта в документации, где видно, что сначала выполняется body, а потом OnInit скрипта. Т.е. с точки зрения main они равнозначны  - выполняются до main. А вот у же с точки зрения OnInit отсутствие body - это недостаток, т.к. когда проект состоит из десятков файлов со своей инициализацией, то контроль за процессом запуска только в OnInit - это сложно.

И с таким подходом, OnInit - совсем не обязательная сущность.Возможно я не понял это, но максимум, что можно сделать до main - это прочитать что-то с диска. Ни о каких восстановлении состояния речи не может быть, т.к. восстановление подразумевает и актуализацию после подключения к серверу. Если это просто чтение, то да. Но и это я тоже не делаю в OnInit, т.к. скрипт может не останавливаться и работать сутками без выключения терминала. Это значит, что OnInit вызвался вчера, а сегодня что? Надо же после восстановления связи с сервером и обновления таблиц тоже актуализировать состояние, проверить что случилось, что есть в данных и т.д. И делать это надо при старте каждого дня пока скрипт работает. А работать он может месяцами.

Поэтому OnInit - это технический колбек, просто сигнализирующий, что код исполненный выше в body скрипта при его запуске, не привел к ошибкам. Ничего более. Делается это один раз при запуске. Поэтому там и могут быть только сугубо технические действия именно при запуске скрипта и ничего более.