Добрый день. Подскажите, пожалуйста. Функция _trans2quik_transaction_reply_balance в transaction_reply_callback возвращает остаток. Остаток что она возвращает? Можно ли одновременно организовать advise loop для двух таблиц quik по DDE? Есть ли ещё способы вывода данных во внешнюю программу из таблицы кроме DDE, ODBC и текстового файла? В частности интересует получение данных о состоянии клиентского портфеля. Спасибо.
John написал: Подскажите, пожалуйста. Функция _trans2quik_transaction_reply_balance в transaction_reply_callback возвращает остаток. Остаток что она возвращает?
Это не исполненный остаток в заявке. Например при снятии заявки, которая была частично исполнена, будет указано не исполненное количество.
Цитата
John написал: Можно ли одновременно организовать advise loop для двух таблиц quik по DDE?
К сожалению затруднимся с ответом. Если работает, значит можно.
Цитата
John написал: Есть ли ещё способы вывода данных во внешнюю программу из таблицы кроме DDE, ODBC и текстового файла? В частности интересует получение данных о состоянии клиентского портфеля. Спасибо.
Из клиентских способов, можно использовать QLUA, который умеет передавать данные в том числе и в Вашу DLL. Если интересуют более серьезные решения, то это модуль экспорта Он умеет выводить в том числе и состояние портфеля. По вопросу приобретения, следует обратиться к брокеру.
Подскажите ещё, пожалуйста. В функцию TRANS2QUIK_TRADE_STATUS_CALLBACK передаются параметры: dPrice – цена сделки, dValue – объём сделки, nQty – количество сделки. Чем цена сделки отличается от объёма сделки, и в чем выражается? Количество сделки - это количество лотов в сделке? Цена сделки учитывает все комиссии?
Цитата
Sergey Gorokhov написал: Это не исполненный остаток в заявке. Например при снятии заявки, которая была частично исполнена, будет указано не исполненное количество.
В чем выражается не исполненный остаток? В денежных единицах, в количестве лотов, в количестве акций?
John написал: Чем цена сделки отличается от объёма сделки, и в чем выражается?
На самом деле Ваш вопрос не связан с программированием и TRANS2QUIK в частности. Это банальные основы торговли. Цена это за сколько был куплен или продан один лот. Объем вычисляется по формуле Для акций формула такая: «Объем» = «Цена» * «Количество» * «Размер лота», Для облигация такая: «Объем» = «Количество» * («Цена» * «Номинал» / 100 + «НКД») Для фьючерсов: «Объем» = «Количество» * «Стоимость шага цены» * («Цена» / «Размер шага цены»), Все это есть в документации на терминал QUIK
Цитата
John написал: Количество сделки - это количество лотов в сделке?
Sergey Gorokhov написал: Цена это за сколько был куплен или продан один лот.
Наверно, все же это цена акции исходя из формулы: «Объем» = «Цена» * «Количество» * «Размер лота».
Из trade_status_callback можно вызвать функции: double __stdcall TRANS2QUIK_TRADE_TS_COMMISSION (intptr_t nTradeDescriptor) – возвращает величину суммарной комиссии по сделке;
double __stdcall TRANS2QUIK_TRADE_EXCHANGE_COMMISSION (intptr_t nTradeDescriptor) – возвращает величину комиссии за торги по сделке;
double __stdcall TRANS2QUIK_TRADE_TRADING_SYSTEM_COMMISSION (intptr_t nTradeDescriptor) – возвращает величину комиссии за технический доступ по сделке;
double __stdcall TRANS2QUIK_TRADE_BROKER_COMMISSION (intptr_t nTradeDescriptor) – возвращает сумму комиссии брокера;
Есть ли более подробная информация о значении возвращаемых величин?
И если вернуться к _trans2quik_transaction_reply_balance, то как она, и 4 выше перечисленные функции вызывается. Их нет в библиотеке trans2quik.
John написал: Есть ли более подробная информация о значении возвращаемых величин?
А что именно не понятно из имеющегося описания?
Цитата
John написал: И если вернуться к _trans2quik_transaction_reply_balance, то как она, и 4 выше перечисленные функции вызывается. Их нет в библиотеке trans2quik.
Они там есть. Быть может у Вас версия устаревшая. Проверьте этот момент.
Есть опция исполнения заявки «поставить в очередь» или «put in queue». Я так понимаю, если заявка исполняется частично, то вызывается функция transaction_reply_callback с обновленным значение quantity, как минимум обновляется количество лотов. Например: есть гипотетическая первоначальная заявка с количеством лотов = 3, присвоенный мной transId=208, orderNum, присвоенный сервером Quik, есть значение transaction_reply_ballance = 0. Что из всего этого изменится, а что останется прежним, когда заявка будет исполняться частично. Если по первоначальной заявке продано два лота из трех, то сервере выставляется новая заявка, вызывается transaction_reply_callback, параметр qauntity = 1, transId, orderNum – не понятно чему равны или определяются сервером при регистрации(orderNum понятно, что задается только сервером, но останется ли он тем же или изменится - вопрос. Хотя по логике, должен измениться), transaction_reply_ballance = 1. Как в transaction_reply_callback идентифицировать какая именно заявка была частично реализована. По моим представлениям, в данном случае, должен сохранится либо transId, либо orderNum, либо и то и другое.
Для решения этой задачи, возможно, можно использовать trade_status_callback, в которой есть две величины: dOrderNum - номер заявки породившей сделку, trans2quik_trade_transid – возвращает transid, заявки породившей сделку. Если первоначальная заявка дробится, то в trade_status_callback какими будут значения dOrderNum и transid? Транс ид будет равен 208, как в предыдущем абзаце, т.е. присвоенный мной? А dOrderNum будет равен ордер наму до частичного исполнения заявки?
Цитата
А что именно не понятно из имеющегося описания?
В частности интересует суммарная комиссия по сделке, если такую величину можно получить. И, например, зависимость между величинами: TS_COMMISSION = EXCHANGE_COMMISSION + SYSTEM_COMMISSION + BROKER_COMMISSION.
Цитата
Они там есть. Быть может у Вас версия устаревшая. Проверьте этот момент.
Да, действительно, версия 1.2. В версии 1.3 все это есть. Где-то читал, что версия 1.3 под х64 ОС. Возможна ли её работа под управлением 32-битной оболочки?
John написал: Я так понимаю, если заявка исполняется частично, то вызывается функция transaction_reply_callback с обновленным значение quantity, как минимум обновляется количество лотов.
Да, но только если частичное исполнение произошло сразу же в момент выставления заявки. Если частичное исполнение произошло позже, то ловить изменения следует в заявках TRANS2QUIK_ORDER_STATUS_CALLBACK.
Цитата
John написал: Если по первоначальной заявке продано два лота из трех, то сервере выставляется новая заявка
Это не правда, кто Вам такое сказал? Если заявка частично исполнилась, то она и дальше будет висеть пока не исполнится, либо пока ее не снимут (Вы или биржа) Другое дело, если Вы сами ее снимаете при частичном исполнении и сами выставляете новую заявку. Но тогда это будет именно что новая заявка.
Цитата
John написал: Если первоначальная заявка дробится, то в trade_status_callback какими будут значения dOrderNum и transid?
dOrderNum и transid не меняются если не меняется заявка. По одной заявке может быть сколько угодно сделок, но заявка то одна и dOrderNum у нее будет один. Тоже касается и transid.
Цитата
John написал: В частности интересует суммарная комиссия по сделке, если такую величину можно получить
Ответ есть в Вашей же цитате:
Цитата
John написал: Из trade_status_callback можно вызвать функции: double __stdcall TRANS2QUIK_TRADE_TS_COMMISSION (intptr_t nTradeDescriptor) – возвращает величину суммарной комиссии по сделке;
Цитата
John написал: Где-то читал, что версия 1.3 под х64 ОС. Возможна ли её работа под управлением 32-битной оболочки?
Да, 1.3 под х64 ОС. К сожалению х32 битная операционная система не дает работать х64 битным приложениям.
Sergey Gorokhov написал: Просьба уточнить где Вы взяли версию 1.3 под х32?
Я нигде не брал. Сейчас я с ней не работаю.
Просто логика подсказывает, что если есть х64, то должна быть и х32, разве нет? И в этом ключе, ваши слова о том что в 64хбитной есть функции которых нет в 32х, меня сильно удивили.
Да, но только если частичное исполнение произошло сразу же в момент выставления заявки. Если частичное исполнение произошло позже, то ловить изменения следует в заявках TRANS2QUIK_ORDER_STATUS_CALLBACK.
Что подразумевается под: «сразу же в момент выставления заявки» и «если частичное исполнение произошло позже»? Понимаю так: «сразу же в момент выставления заявки» - т.е. в момент после отправки заявки через, например, send_async_transaction и до вызова transaction_reply_callback происходит частичное исполнение заявки на сервере, и в transaction_reply_callback функция transaction_reply_balance(которая имеется только в версии dll 1.3) возвращает значение меньшее, чем количество лотов, выставленное при отправке транзакции на сервер. А под «если частичное исполнение произошло позже» понимаю то, что частичное выполнение заявки произошло после возврата функции из send_sync_transaction, либо после вызова transaction_reply_callback, в случае асинхронной отправки транзакции. Так это или нет?
Цитата
Это не правда, кто Вам такое сказал?
Чистая гипотеза. Может, плохо читал manual.
Цитата
На самом деле Ваш вопрос не связан с программированием и TRANS2QUIK в частности. Это банальные основы торговли. Цена это за сколько был куплен или продан один лот. Объем вычисляется по формуле Для акций формула такая: «Объем» = «Цена» * «Количество» * «Размер лота»,
Цитата
Наверно, все же это цена акции исходя из формулы: «Объем» = «Цена» * «Количество» * «Размер лота».
Все-таки определение параметра в order_status_callback «dPrice – цена заявки» не совсем информативно. Более понятно – «цена инструмента в заявке», или на худой конец, «цена указанная в заявке». Тоже относится и к trade_status_callback. Приходится догадываться, что же имеется в виду.
В документации Quik в объявлениях на те же функции order_status_callback и trade_status_callback в качестве типа данных параметра указан _int64 nBalance и _int64 nQty. Библиотеку использую версии 1.2. Т.е. 32-ух битную. Хотя возникает справедливое замечание по поводу того, почему бы не получить 32-ую версию с полным функционалом версии 1.3. Может, конечно, в этом есть какие-то сложности, но переходить на ОС 64 бита для использования версии 1.3. Вот возвращаясь к, язык программирования использую не СИ, int64 в прямом виде не доступен, но есть эквивалент. Используя эквивалент int64, получаю app crash при вызове order_status_callback и trade_status_callback. Явно неправильный формат стэка. Глядя в пример на VBA, вижу тип данных long(т.е. для VBA это 32 бита) вместо аналога int64. Т.е. для СИ, на мой взгляд, объявление должно выглядеть для 32-ой библиотеки как: long int nBalance или int nBalance или dword nBalance. Как это более логично. Возможно, что документация на quik описана с прицелом на 64-ую ОС и версию dll 1.3 . Но с 32-ой величиной все выполняется без ошибки. Какой фактически используется в данном случае тип данных? Опять же тип данных dNumber, dOrderNum - insigned_int64, может сбить с толку. Если это стандартный тип данных, то какой-то странный. Если используется псевдоним типа данных, то какой стандартный тип данных за ним стоит, тоже вопрос. Такие нюансы могут привести к трудноопределяемым ошибкам, которые как бы не пришлось вылавливать на стадии тестирования или ещё хуже регулярной работе.
Вот ещё такой вопрос возник. В order_status_callback и trade_status_callback приходит несколько одинаковых вызовов, два или три. Где-то читал, что данная практика является вариантом нормы, после внесения некоторых изменений в порядок работы. В принципе, это не было бы для меня проблемой, если бы не частичное исполнение сделки. Как обрабатывать информация в trade_status_callback – не понятно. Например:
Оформляем заявку на покупку 3 лотов. Заявка частично исполняется, приобретается один лот, в order приходит три вызова(или не приходит и приходит только один вызов не количество частичных исполнений?), с информацией dPrice – цена акции, dValue – общая стоимость, в данном случае одного лота, nBalance – неисполненный остаток – 2 лота. Следом ещё два таких же сообщения, которые можно проигнорировать. Что видим в trade. dPrice – цена инструмента, dValue – количество сделки, в данном случае один лот, nQty – количество сделки, т.е. один лот. Далее получаем ещё два вызова с такими же данными. Игнорируем их. Следом идет ещё один вызов, т.е. уже 4-ый по счёту, но уже не дубль, а реальная сделка с опять же реализованным одним лотом(т.е. количество не реализованных лотов в заявке равно одному). И параметры этой сделки точь в точь повторяют оные в трех предыдущих. Как отличить дубль от реального трейда? Либо: 1. Один вызов на один трейд, 2. Четкая последовательность и количество дублей. Т.е. известно, что дубли идут только после реального трейда, и их количество равно именно двум, не больше, не меньше, 3. Либо присылать в каждом последующем трейде общее количество купленных лотов. Т.е. nQty в trade_status_callback не 1, 1 – как в примере выше, а уже 1, 2(1+1=2).
Такого рода проблема возникает именно при появлении возможности частичного исполнения заявки. Если бы она исполнялась строго полностью, то паразитные вызовы не имеют значения, их можно игнорировать. Понятно, что можно указать в execution_condition= fill or kill, но это менее гибко, чем put in queue. Хотелось бы определить четкий вариант действий в данной ситуации, но в руководстве об этом ни слова, соответственно уверенности тоже никакой, только уровень догадок и предположений.
John написал: Что подразумевается под: «сразу же в момент выставления заявки» и «если частичное исполнение произошло позже»? Понимаю так: «сразу же в момент выставления заявки» - т.е. в момент после отправки заявки через, например, send_async_transaction и до вызова transaction_reply_callback происходит частичное исполнение заявки на сервере, и в transaction_reply_callback функция transaction_reply_balance(которая имеется только в версии dll 1.3) возвращает значение меньшее, чем количество лотов, выставленное при отправке транзакции на сервер. А под «если частичное исполнение произошло позже» понимаю то, что частичное выполнение заявки произошло после возврата функции из send_sync_transaction, либо после вызова transaction_reply_callback, в случае асинхронной отправки транзакции. Так это или нет?
Для начала, сервер QUIK никакого отношения к исполнению заявок не имеет, они исполняются на бирже. И заявка на бирже, может частично исполниться в момент выставления. Поставьте заявку с наихудшей ценой и количеством больше чем есть в стакане и увидите сами. В callback на транзакцию Вы получите что то вроде "заявка такая-то зарегистрированна, исполнено столько-то." и balance вернет количество которое не исполнилось. это и есть «сразу же в момент выставления заявки». А если поставить заявку с ценой по хуже, то она может исполниться когда-нибудь потом, через час, два или несколько лет, в зависимости от самой заявки.
Цитата
John написал: Возможно, что документация на quik описана с прицелом на 64-ую ОС и версию dll 1.3 .
Так и есть, в документации на терминал начиная с версии 7.0 написано только для dll версии 1.3.
Цитата
John написал: Какой фактически используется в данном случае тип данных?
В версии 1.2 используйте Long вместо _int64
Цитата
John написал: Опять же тип данных dNumber, dOrderNum - insigned_int64, может сбить с толку. Если это стандартный тип данных, то какой-то странный.
вполне нормальный тип данных, даже в MSDN о нем написано. в качестве аналога, на версии 1.2 используйте double
Цитата
John написал: Такие нюансы могут привести к трудноопределяемым ошибкам, которые как бы не пришлось вылавливать на стадии тестирования или ещё хуже регулярной работе.
В связи с чем, рекомендуем использовать актуальные версии ПО.
Цитата
John написал: В принципе, это не было бы для меня проблемой, если бы не частичное исполнение сделки.
Сделка, даже теоретически не может исполниться и уж тем более частично, Вы что-то путаете. А вот заявка, да может исполниться частично
Цитата
John написал: order приходит три вызова(или не приходит и приходит только один вызов не количество частичных исполнений?),
Придет столько вызовов сколько было обновлений на заявке. "обновление" в данном случае не только исполнение, а вообще любое изменение какого-либо параметра на заявке, например установка UID на заявке. То же касается и сделок.
Цитата
John написал: Как отличить дубль от реального трейда?
"дубли" сделок и есть "реальный трейд", следует понимать что "дубли" это обновление реальной сделки а не другая сделка или фейковая сделка. у "дублей" (если это именно обновление конкретной сделки), будет одинаковый номер сделки. Если номер уже другой, это уже другая сделка. По одной заявке может быть несколько сделок и это нормально.
В связи с чем, рекомендуем использовать актуальные версии ПО.
Для торгового терминала, какая версия считается актуальной в плане отсутствия ошибок? Понятно, что нужно смотреть по списками изменений, если сложно, то ладно, устанавливай последнюю. Но вопрос в том, что система поддержки ПО отличается от стандартной, выпуск заплаток происходит одновременно с обновлением функционала.
Какая версия 32-битной библиотеки считается актуальной? Или актуальна только версия trans2quik 1.3 для х64? Устраняются ли ошибки в 32-ой версии? И где посмотреть интерфейс функций версии 1.2? В версии руководства 6.17 все я так понял заточено под dll 1.3. В списке изменений терминала для версии 7.0 имеется ссылка на новую библиотеку, по всей видимости, имеется ввиду версия 1.3, которая работает только с версиями терминала 7.0 и выше, и «старая» версия библиотеки, по всей видимости – это версия 1.2. Будет ли старая версия работать со всеми версиями терминала или есть какие-то ограничения?
Цитата
вполне нормальный тип данных, даже в MSDN о нем написано.
В MSDN есть тип данных unsigned_int64, но нет упоминания о insigned_int64.
Параметр nMode в order_status_callback и trade_status_callback. Что понимается под новой заявкой, как определяется, что заявка именно новая, а не начальная рассылка?
Есть ли строгая очередность вызова функций transaction_reply_callback order_status_callback, trade_status_callback при выполнении заявки? Т.е. order_status_callback и trade_status_callback не будут вызваны пока не будет вызвана transaction_reply_callback, после вызова transaction_reply_callback будет вызвана order_status_callback, но никак не trade_status_callback, если идет обновление иформации о сделке, то сначала вызывается order_status_callback затем trade_status_callback и т.п.
John написал: Параметр nMode в order_status_callback и trade_status_callback. Что понимается под новой заявкой, как определяется, что заявка именно новая, а не начальная рассылка?
Вопрос не совсем понятен. А что такое первоначальная рассылка? Если речь про то как отличить загрузку старых данных от свежих, то только по времени.
Цитата
John написал: Есть ли строгая очередность вызова функций transaction_reply_callback order_status_callback, trade_status_callback при выполнении заявки?
Порядок колбеков нигде со стороны QUIK специально не проверяется. Все едет в том порядке как приехало с биржи. В связи с чем нет никаких гарантий что порядок будет соблюден.
nMode. Тип: Long. Признак того, идет ли начальное получение сделок или нет, возможные значения: «0» – новая сделка, «1» – идет начальное получение сделок, «2» – получена последняя сделка из начальной рассылки;
Каким образом отличается "новая сделка" от "начального получения сделок"? Это как-то связано с вызовом функции start_trade, start_order? Например: если не сразу была оформлена подписка на получение инструментов через subscribe_order, start_order, но до этого момента были получены в терминал заявки от сервера, то в момент первого вызова callback для order эти заявки будут считаться начальной рассылкой. Поправьте, если где-то напутал.
Добрый день. Есть такие величины как время сервера, дата сервера. Можно ли как-то передать эти данные через DDE обмен. Под «время сервера, дата сервера» понимается отсчет биржей начала торговой сессии и её конца, а также время и дата, которые указываются при заключении сделки. Т.е. в этом случае нужна таблица, в которой бы содержались поля с текущей датой. Что скорее все маловероятно. Lua скрипт на данный момент не рассматриваются. Может у ПО сервера биржи есть опция по синхронизации времени с внешним сервером точного времени - time provider. Если в этом случае настроить синхронизацию с тем же сервисом, то можно косвенно обеспечить получение времени и даты сервера биржи. Или это не надежный вариант?
John написал: Есть такие величины как время сервера, дата сервера
Есть такие величины как время сервера QUIK, дата сервера QUIK, время биржи, дата биржи, и это совершенно не одно и тоже. Даже более того на одном сервере QUIK Вы можете одновременно работать с разными рынками и биржами и время на них может быть разным. Для примера, сравните таблицу обезличенных сделок по фортс и по акциям, на удивление, при одновременном появлении там следок, время на них разное. И это только на одной Московской Бирже, а ведь QUIK умеет работать и с другими. Пока все биржи мира друг с другом не договорятся, придется с этим как-то жить. В связи с чем, со стороны QUIK нет смысла синхронизации времени с биржей. Просто потому, что не известно с какой именно биржей нужно синхронизоваться. Хотя технически такая возможность есть, впрочем как и на любом другом компьютере.
Цитата
John написал: Может у ПО сервера биржи есть опция по синхронизации времени с внешним сервером точного времени - time provider.
Это опция есть на любом компьютере, в том числе и на компьютерах серверов биржи и на Вашем компьютере тоже. Синхронизация настраивается в "панель управления" - "дата и время".
Цитата
John написал: Если в этом случае настроить синхронизацию с тем же сервисом, то можно косвенно обеспечить получение времени и даты сервера биржи. Или это не надежный вариант?
Это надежный вариант, но с учетом ряда особенностей: Во-первых, нужно знать с каким NTP сервером Вам нужно настроить синхронизацию. Уточните у специалистов нужной биржи, какой NTP сервер использовать (с учетом того что на разных рынках одной биржи, время тоже может быть разным). Во вторых, готовьтесь к тому что в любом случае будет какая-то погрешность. Возможно она будет не существенной, какие-то сотые доли секунд, но все-же она будет. И в-третьих, поменяйте батарейку на материнской плате, так на всякий случай.
Спасибо за ответы. Подскажите, как можно определить факт установки торгово-информационнго терминала Quik? Хотелось бы найти разумный способ определения пути к исполняемому файлу info.exe. Имеется установленный Quik, но незадача, записи в \HKEY_CURRENT_USER\SOFTWARE\ - нет. Можно, конечно, осуществить поиск по всем разделам и дискам, но это уже крайний случай, либо ввести путь вручную. Есть ли запись в реестре windows с параметром пути к info.exe? Если нет, то можно было бы добавить информацию при установке приложения, стандартная практика.
Но если это вопрос безопасности, анонимности или прочий значимый повод, то конечно лучше оставить реестр чистым. Я просто не в курсе данных вещей, а мою проблему можно решить и другим путем. Спасибо.
Иван написал: Добрый день. Почему в таблице обезличенных сделок QUIK нормальное время, а при выводе через ODBC с датой? Как с этим бороться?
Добрый день,
Просьба сообщить версию Рабочего места QUIK и прислать скриншоты, на которых видна проблема с наименованием выводимого параметра в QUIK и получаемого вашей БД.