foobar (Автор тем)

Добрый день,
хочу попробовать написать поддержку MOVE_ORDERS  в своём ПО. Из документации немного непонятно, что будет записано в pdOrderNum после выполнения заявки.
Для "обычных" заявок там ИД из торговой системы, который я получаю и привязываю к моему TRANS_ID когда TRANS2QUIK_SEND_SYNC_TRANSACTION возвращает ответ. Но в документации на MOVE_ORDERS указано что он поддерживает до двух заявок. Как мне в синхронном режиме узнать ID новых заявок?
Я правда не планирую переставлять сразу 2, но pdOrderNum хочется получить сразу же.

Когда Квик расчитывает греки по БШ, он имеет представление о времени экспирации опциона (0 дней в модель Блека-Шоулза ведь не поставишь, следовательно там скорее всего минуты, а на доске опционов временная стоимость в дату экспирации как-то считается).  Откуда Квик берёт время экспирации для расчёта греков? В таблице текущих торгов не нашёл (есть дней до экспирации, дата экспирации). Есть расписание сессий, но при экспирации квартальных на валюту есть нюансы, которые просто так не учтёшь.

Мне бы таймштамп (дата + время) экспирации любого опциона очень бы пригодился.

Скачал обновление от брокера, версия 8.11.0.66
Там появилась новая таблица с фильтрами, но сохранённые данные сбрасываются при рестарте терминала. (если не перезапускать, то изменения работают и отражаются при открытии меню). На картинке прицепил дефолтное состояние настроек таблицы. Переключатель умный/по выбранным классам сохраняется.

Ручной вызов "сохранить настройки в файл" так же не помогает. Что можно ещё попробовать? Мне нужно добавить класс SPBOPT со снятыми фильтрами, чтобы в экспорт через LUA автоматически наползали новые недельки.

Смотрю коды в документации на QPILE, так как в QLUA.chm кодов вообще нет. В QPILE есть код SECTYPE, но похоже, он не существует.


Судя по result такого кода нет. У меня в таблицу текущих параметров вытянуты классы TQBR, SPBFUT, SPBOPT и в колонке всё выглядит красиво.

В документации ответа на вопрос не нашёл.
Предположим, мы хотим послать набор из 20 параметров из таблицы текущих торгов. В документации есть такой пример

в callback OnParam вызываем GetParamEx по нужному классу-коду-параметру, записываем в глобальную табличку и в main() её вычитываем, чтобы не лочить поток обработчика.
Вопрос такой: GetParamEx работает над копией строки, которая была обновлена или нет?

Вопрос связан с тем, что вызвав GetParamEx() 20 раз, я получу неконсистентные данные (пока получаю параметры поштучно строка изменяется) или всё будет хорошо? Мне бы получить оригинальную строку, которая бы была в Таблице текущих торгов.

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

В результате сверки, несколько (да, всегда пара штук в день) минуток не совпадает с пересчётом по тикам. Выяснилось, что предположение соблюдается не всегда. Как видно на картинке, в классе SPBXM начали поступать данные из 15:38 минутки, но тут внезапно ET_SPB досылает свою сделку из 15:37-й. При этом, счётчик показывает, что тик народился после более позднего. Это нормально? И как поздно может придти тик в принципе?

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

- ALZ0 2020-09-14 21:54:40.000000 1 лот
- ALU0 2020-09-14 22:04:00.000000 14 лотов

Как такое возможно?

Добрый день, у меня снова проблемы с экспортом по DDE.

настроен экспорт 7 таблиц из Квик по DDE. C 5 таблицами никаких проблем нет вообще, с двумя - есть.

Обе таблицы - Текущие торги. Происходит всё по такому сценарию каждый день:

1. Сервер брокера отключается (или выкидывает клиентов около 09:00).

2. Квик настроен на очистку данных при смене Даты на сервере (очистка при смене дат на клиенте приводит к такому же результату).

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

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

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

Остальные таблицы не отваливаются и экспортируются без проблем. Второй Квик, который не экспортирует таблицы Текуших торгов (данные таблицы, понятное дело, одинаковые) на том же DDE сервере, работает месяцами без всяких проблем.

Хотелось бы, чтобы экспорт стартовал сам, без дополнительных действий пользователя. Что можно сделать?

В таблице текущих параметров экспортируются классы: TQBR, SPBFUT, SPBOPT (все инструменты).

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

Код класса, код инструмента, ISIN, Инструмент сокращённый, Инструмент, Лот, Макс. возм. цена, Мин. возможная цена, Шаг Цены, Точность, Стоимость шага цены, Класс базового актива, Баз. Актив, Дата исп, Сессия, Тип инструмента, Тип опциона, Страйк, До погашения

Добавлены все инструменты в классах: TQBR, SPBFUT, SPBOPT.

Как видите, данные относительно редко изменяемые.

С целью тестирования в таблице были оставлены: SiU0 и все опционы на него. Первый инструмент ликвидный, все остальные - не очень.

При запуске вся таблица выгружается целиком (это нормально).
Потом выгружаются единичные сделки, большей частью по Си
Через минуту выгружается вся таблица целиком и этот процесс повторяется снова и снова каждую минуту.
Это создаёт характерную пилу на графике СУБД. Таблица из 20к строк выгружаемая раз в минуту что-то да хочет в плане ресурсов. Это можно как-то отключить или рассказать зачем выгружать данные, которые заведомо не менялись?
Квик 8.6

Решил добавить экспорт всего SPBFUT (до этого экспортировался TQBR, проблем не было). Удалил файл alltrades.dat, quik.log
Наблюдаю очень странный эффект: вечерка 25.06.2020 выводилась в таблицу как 26.06.2020
Как такое возможно? У меня вся база из-за этого поломалась.
Пример:
https://i.imgur.com/1qY8JBM.png Этот ID (26057566584852) соответствует сделке на вечерней сессии 25.06.2020, но в ленте принтов  в колонке Дата торгов он идёт как 26.06.2020
Почему такое происходит?

Просьба добавить в таблицу Позиции по инструментам класс инструмента, как это сделано в большинстве других таблиц. Конечно, там уже есть ISIN, но он не у всех классов (например, CETS, SPBFUT). В таблице уже есть Код Инструмента, класс бы позволил однозначно идентифицировать инструмент при экспорте таблицы.

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

Есть ли какие-нибудь варианты? Хорошо бы, чтобы уведомления о нуле приходили.

Добрый день.

Возникло желание привязывать сделки к ордерам из внешней системы через ID транзакции.
Из документации на таблицу заявок: "Значение уникального номера заявки TRANS_ID при импорте заявок из файла"
Из документации на таблицу сделок: "Значение уникального номера заявки TRANS_ID, породившей сделку"

Импортируем сделки по API - всё хорошо.
Создаём сделку руками:
1. В таблице заявок TRANS_ID пуст
2. В таблице сделок TRANS_ID не пуст. Там используется какой-то другой счётчик.

Отчего так?

В разделе 6 руководства описан функционал экспорта инструментов по ODBC.
Очень бы хотелось иметь аналог по DDE. Хочется искать плиты в стаканах :)

На мой взгляд DDE гораздо лучше ODBC, странно что его обделили вниманием.

1. Он быстрее, так как осуществляется через shared mem
2. Он позволяет не мучиться с генерацией сигналов об обновлении данных. (В случае через ODBC, к примеру, это означает или использовать триггеры или читать журнал транзакий, что медленнее на несколько порядков)