Андрей (Все сообщения пользователя)

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1
Перемещение заявки 2 транзакциями
 
Цитата
Roman Azarov написал:
Андрей,

Цитата
Андрей написал:
Эмулировать - значит дать пользователю 1 вызов API, а в нем инкапсулировать KILL_ORDER и NEW_ORDER, с правильной и оптимальной реализацией ожидания между ними.
Для чего? Пока сервером не будет получен ответ от биржи о том, что заявка была успешно снята, транзакция на выставление новой заявки не пройдет контроль достаточности средств на сервере.

Цитата
Андрей написал:
Вот у меня вопрос - как в точности реализовано перемещение ордера мышкой в стакане?
Точно так же. Отправка KILL_ORDER, ожидание ответа от биржи, проверка NEW_ORDER на сервере, отправка NEW_ORDER на биржу.
Такую же логику Вы можете реализовать и в собственном скрипте.

Повторимся, пауза между KILL_ORDER и NEW_ORDER (помимо минимальных сетевых задержек) обусловлена ожиданием ответа от биржи, исключить этот момент нельзя.
Во первых для того, что, как минимум, исключаются раундтрипы между клиентом и сервером квик, а это уменьшает общую задержку. Сервер "на коротке" общается с биржей. А вы замерьте, какой % от текущего сетевого ожидания занимает этот путь сервер-биржа. Далее, конкретно, вы ждете onTransReply на KILL_ORDER? Я попросил ответить максимально точно и детально, какого технического сигнала вы ждете. Тут справедливо замечают, что реплай приходит иногда и долше обычного. А перемещение ордера мышкой работает быстрее. Посмотрите точнее данную реализацию. Так же замечу, что реплай на KILL_ORDER почти всегда успешен. Можно было бы и подумать, как оптимизировать и допускать авансом разблокирование лимита. Но ладно, это отдельная тема, пока не об этом. А о том, что внутренние механизмы сигналов (даже не колбеки lua) и обработка связки удаление+создание на сервере дали бы, уверен, неплохое уменьшение задержки.
Перемещение заявки 2 транзакциями
 
Цитата
Roman Azarov написал:
Андрей, добрый день!

Давайте попробуем изложить свой ответ подробнее.
В  биржевом  интерфейсе для фондового рынка нет транзакции MOVE_ORDERS. Соответственно, заменить заявку на бирже каким-либо иным образом, кроме как снять ее и затем выставить снова - невозможно. Что конкретно и на каком этапе Вы предлагаете "эмулировать", если биржевым интерфейсом поддерживаются только KILL_ORDER и NEW_ORDER?
Если Вы хотели бы видеть транзакцию для замены заявки, рекомендуем обратиться с подобным пожеланием на биржу.

Что касается "пропуска" проверок, то здесь вынуждены снова повториться:
Поскольку контроль достаточности Ваших средств (как клиента) выполняется брокером (средствами сервера QUIK), биржа не в курсе, сколько  именно Вам  доступно средств.
Лимиты же обновляются только после получения ответа от биржи (о том, что заявка успешно снята/выставлена или же получена ошибка) и это единственный правильный вариант.
Вы можете попробовать обратиться к своему брокеру с просьбой не контролировать Ваши позиции и сразу отравлять транзакции на биржу, однако, предполагаем, что его ответ будет достаточно очевидным.  
Эмулировать - значит дать пользователю 1 вызов API, а в нем инкапсулировать KILL_ORDER и NEW_ORDER, с правильной и оптимальной реализацией ожидания между ними. Вот у меня вопрос - как в точности реализовано перемещение ордера мышкой в стакане? Вы понимаете, что я спрашиваю про паузу между KILL_ORDER и NEW_ORDER по большей части. Там самая оптимальная реализация?
Перемещение заявки 2 транзакциями
 
Надо, Федя.. надо..
Вполне простая вещь - передвинуть заявку. Для клиента это по смыслу одна операция. Даже чисто технически это сложно сейчас сделать, разбивая на стадии, ожидая колбеки после снятия.. Ожидание разблокирования лимитов при KILL_ORDER можно и нужно оптимизировать. Как минимум в рамках вот такой пары - снятие+создание. Которую можно реализовать эмуляцией MOVE_ORDERS.
Перемещение заявки 2 транзакциями
 
Или вы про колбек OnMoneyLimit? Я не измерял насколько он раньше, чем 1й onTransReply, но экспериментально видел, что за 50мс отправлять создание не получается.
В любом случае связку снятие+создание (оптимизация расчета лимитов) можно и полезно реализовать, раз разработчики говорят, что снижекние задержки является приоритетом.
Перемещение заявки 2 транзакциями
 
Это не должно требовать прямого доступа на биржу )
Перемещение заявки 2 транзакциями
 
100-300 это до первого onTransReply по trans_id KILL_ORDER. А ваши события можно получать как-то иначе? Если нет, то очевидно, что ничего быстрее событийная модель не обеспечивает. Зачем мириться, если все достижимо, надо только доработать алгоритм снятия лимитов при KILL_ORDER. Чтобы не ждал лишнего от биржи, а делал это авансом, грубо говоря. Всё там возможно. А иначе дело даже не в "на всю котлету". В первом сообщении я писал про ошибку изменения ордера продажи своих, не маржинальных, акций. В шорт их не дают. Соответственно, даже при свободных лимитах, переставить не получается. Без доплаты - а что тут прикольного? Это очевидная вещь - оптимизировать связку снятие+создание как единую логическую операцию.
Перемещение заявки 2 транзакциями
 
Как MOVE_ORDERS в режиме 1 и с 1 заполненной заявкой из двух.
Перемещение заявки 2 транзакциями
 
Цитата
s_mike@rambler.ru написал:
Сделать снятие на бирже двух заявок "мгновенно" не может никто. Ни скрипт, ни сервер, ни даже биржа.

даже на срочном рынке, где транзакция move_orders исполняется по одному приказу, снятие заявок происходит последовательно. При этом возможны ситуации, когда одна заявка будет снята, а вторая не будет, а будет уже исполнена или частично исполнена.
О снятии 2 речи не идет. Мы про снятие+создание с оптимизацией контроля лимитов в этой операции.
Указанные особенности MOVE_ORDERS понятны и ничему не противоречат.
Перемещение заявки 2 транзакциями
 
В идеале предлагаю реализовать эмуляцию типа транзакции MOVE_ORDERS в системе QUIK, раз этого нет в биржевом интерфейсе. Это можно реализовать куда оптимальнее на вашей стороне, чем 2 транзакциями как сейчас. Или как минимум сделать учет снятия мгновенным и действующим для последующих NEW_ORDER. Можно для этого как-то отдельно оформить вызов, если не хотите менять текущий механизм. Но это уже будет инструмент.
Перемещение заявки 2 транзакциями
 
Событийная модель и приводит к тому, что создание ордера требует паузы в 100-300мс после снятия. Надо думать как обеспечить функционал, аналогичный MOVE_ORDERS срочного рынка. Почему там это есть, а здесь нет?

"Заявки с разными ценами, так что средств от первой заявки может не хватить на вторую, так что проверка достаточности средств необходима." -
ок, пусть проверяется, но уже с учетом снятия исходной суммы. Это я и имел ввиду в п.2.

"Потому как сервер QUIK в данном случае - единственная проверка достаточности средств в случае фондового рынка.
С точки зрения биржи (для фондового рынка) все операции выполняются на счете брокера, на весь лимит брокера."
Тогда я не совсем понимаю, чего ждет сервер QUIK от биржы на клиентский KILL_ORDER.

"Так что только самостоятельно, ручками в своём роботе каждому придётся решать эту задачку" - я за, но сейчас нет такого инструмента. Я никак не могу отправить изменение ордера за 20мс, хотя очевидно, что лимиты позволяют. Вот простой бизнес-кейс, который нужно обеспечить. Дайте инструмент и нет вопросов ) Но без доплат )
Перемещение заявки 2 транзакциями
 
Цитата
Roman Azarov написал:
Андрей, добрый день!

Контроль достаточности средств клиента на Фондовом рынке МБ осуществляется сервером QUIK, а не биржей.
Разумеется, пока одна из транзакций пройдет проверку на сервере, будет отправлена на биржу, с биржи вернется соответствующий ответ и исходя из него будут изменены Ваши позиции, пройдет какое-то время (исчисляемое в миллисекундах).

Максимально сократить это время - является одной из наших основных задач. Однако, по понятным причинам, реализовать описанное вами невозможно.

В случае, если мы не совсем правильно Вас поняли, просьба подробнее описать, что имелось в виду под
Цитата
Андрей написал:
Либо надо уметь его отключать и пусть все идет на биржу, а там уже получать отказ, если дейтсвительно снятие не отработало.. либо при снятии прописывать инфо в пре-фильтр, чтобы он не ждал чего-то, что ждет сейчас
Когда речь о двух транзакциях NEW_ORDER - все понятно. Но когда это по смыслу одна транзакция типа MOVE_ORDERS, которую приходится технически реализовывать двумя (KILL_ORDER, NEW_ORDER) - требуется доработка для этого особого случая. Чтобы эти транзакции можно было подавать одну за другой без паузы и это не приводило к вышеописанным проблемам с проверкой на сервере Quik.
Сходу приходят 2 пути решения:

1) Сделать вторую версию ф-ции sendTransaction, которая пропускает "проверку достаточности средств на сервере", идет сразу на биржу. Таким образом отправленные 2 транзакции обработаются без проблем, если прийдут на биржу в таком же порядке. Это уже достаточный уровень функционала. В худшем случае биржа просто не обработает вторую транзакцию, Ведь ваша проверка на сервере Quik - это как пре(дварительный)фильтр. Без него ничего страшного тоже не произойдет - получим отказ от биржи в реплае. Порядок будет практически обеспечен малейшей ручной задершкой в скрипте (много меньше текущих 100-300 мс).

2) Сделать проверку на сервере Quik более умной. Когда она получает KILL_ORDER, она уже обновляет предварительно допустимый лимит, чтобы последующая NEW_ORDER прошла проверку не дожидаясь ответа биржи на KILL_ORDER. За исключением вырожденных случаев, KILL_ORDER всегда исполняется биржей, поэтому такая оптимизация ожидания ответа на него - оправдана. Повторюсь, поскольку это префильтр, то его роль не критична. В худшем случае получим отбой от биржи вместо отбоя от сервера квик. Но зато обеспечим указанное эффективное редактирование ордера.

Второй путь сложнее, я бы просто сделал 1) для данного особого (но практически полезного) случая, тем более что это не должно быть сложно.
Перемещение заявки 2 транзакциями
 
Передвижение заявки это ее оптимальное расположение в полученном только что стакане. Для моего алгоритма оно должно быть ASAP. И пофиг на колбеки и их очередность, они обрабатываются потом. Главное обновить стакан. А это мешает сделать какой-то пре-фильтр контроля лимитов и маржинальности, который не успевает получить инфо о снятии. Это не правильно. Либо надо уметь его отключать и пусть все идет на биржу, а там уже получать отказ, если дейтсвительно снятие не отработало.. либо при снятии прописывать инфо в пре-фильтр, чтобы он не ждал чего-то, что ждет сейчас.
Перемещение заявки 2 транзакциями
 
Цитата
Владимир написал:
Андрей, Сколько заявок Вы посылаете в сутки? За каким лешим Вам нужны эти "много мс" - тем более, которые В ПРИНЦИПЕ нельзя обеспечить. Как и порядок следования, кстати.

Фрагмент из ТЗ на мой скрипт.
Неисполненные или частично исполненные заявки снимаются через три минуты активности (период отсчитывается с момента подачи заявки и продлевается после каждой совершённой сделке по этой заявке). Новые заявки по тикеру не открываются в режиме автоматической торговли, пока не закрыты все старые.
МИНУТЫ, блин!
На вкус и цвет роботы у всех разные ) Естественно иногда нужно передвинуть заявку максимально быстро. Не дожидаясь реплая на удаление. Так что нужна ф-ция отправки транзакции в "экспертном режиме", без локальных проверок. Когда программист знает, что делает. Задержку между удалением и созданием он будет делать сам через sleep при необходимости.
Перемещение заявки 2 транзакциями
 
Как известно, на основной секции биржи нельзя это сделать одной транзакцией (а жаль).
В итоге мы сначала снимаем старую заявку, потом создаем новую.
Проблема в том, что между этими транзакциями приходится ждать сколько-то много мс, иначе создание еще не понимает, что перед этим отправлена транзакция снятия. И выдает ошибки типа данный инструмент запрещен в шорт (считая, что продажа еще висит).
Сделайте вторую версию sendTransaction, которая бы не проверяла подобные локальные условия. Чтобы можно было вызывать 2 транзакции сразу друг за другом. Ну или с минимальной задержкой. Чтобы они пришли на биржу в том же порядке и обработались.
MOVE_ORDERS
 
Цитата
Roman Azarov написал:
Андрей, здравствуйте!

1) Обе заявки успешно изменены, либо не изменена ни одна, либо ошибка. Это уже можно понять по реплаю.

2) sec_code не может отличаться у двух данных заявок. Регистрируем пожелание на возможность получения price, quantity и order_num второй заявки?

3) Мы не добавляем в транзакцию поля, которые отсутствуют в биржевом интерфейсе. Так как для данной транзакции в принципе отсутствует направление, добавить его в реплай возможности нет.
Сама задача в принципе не ясна. Данной транзакцией нельзя изменить направление заявки. Зачем необходимо его получать в onTransReply?

На данный момент, рекомендуем получать номер второй заявки из поля result_msg.
Всю прочую информацию же можно получить из таблицы заявок по данному номеру.
Это новость про либо обе, либо ни одна. Об этом хорошо бы написать в документации.
Насчет направления и "из таблицы заявок по данному номеру":
На момент onTransReply нет еще onOrder и записи в заявках. Но в onTransReply есть почти вся смысловая информация о новой заявке. Не хватает только направления и именно для MOVE_ORDERS. И тогда не нужно вести свою базу заявок, ожидающих подтверждения. Ради этого одного поля.

Еще вопрос. Чем обусловлено наличие MODE=0 и MODE=1? Неужели неизменность количества позволяет как-то по особому, заметно эффективнее и т.п. релизовать? Настолько, что даже выделили отдельный режим, а не в рамках частного случая с заданием кол-в MODE=1.
MOVE_ORDERS
 
Цитата
Roman Azarov написал:

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

Цитата
Андрей написал:
Мое предложение - отправлять 2 реплая, с еще одним битом во флаге с указанием на какую заявку из двух каждый. Обоснуйте, почему это не будет улучшением.
Реплай отправляется биржей по достаточно понятной логике - 1 транзакция = 1 реплай.
Можем предложить зарегистрировать пожелание на возможность получения в OnTransReply номеров обеих заявок. Такой возможности на данный момент действительно нет.
1) Нужно по реплаю однозначно понимать статус по обеим заявкам (по отдельности).
2) Добавьте тогда как минимум эти поля по второй заявке (если она есть): sec_code, price, quantity, order_num.
3) Желательно добавить сюда и направление заявок. Даже если этого нет в биржевом интерфейсе, там нет и многих других полей, которые есть в реплае. Вы обогощаете ими. Так включите сюда же и направление 0\1. Например битом, по аналогии как оно заполняется для обычных транзакций (см выше). Но теперь это нужно тоже по обеим заявкам в одном реплае. Поэтому может и отдельным полем сделать. И дублировать его как все вышеуказанные в п.2 для второй заявки, если она есть.
MOVE_ORDERS
 
Цитата
Roman Azarov написал:
Андрей,

1) Прошу прощения, в прошлый раз немного поторопился с ответом. На данной транзакции (MOVE_ORDERS) в принципе нет признака направления. Соответственно, во флагах Вы его и не увидите.

3)  
Цитата
Андрей написал:
И судя по описанию происходит именно 2 транзакции на бирже
Не совсем понимаем, о каком описании идет речь? Это одна транзакция вида MOVE_ORDERS, соответственно, ответ по ней так же будет один.
В данном случае рекомендуем получать номер и прочие поля, относящиеся к заявке из OnOrder().
Послушайте, мы тут делаем предложения по улучшению, а вы даете ответы в стиле "этого нет и такого функционала не предусмотрено". Я вам говорю, что он нужен и легко реализуем.
1) Признак направления заявки есть в самой заявке и он не меняется. Ничто не мешает для унификации его проставлять во flags так же, как для других транзакций. Чтобы в реплае понимать, реплай это на покупку или на продажу. Польза этого сомнений не вызывает, стоимость реализации низкая.
3) В описании про заявки, да.
Перестановка заявок на рынке FORTS выполняется по следующим правилам:
  • Если MODE=0, то заявки с номерами, указанными после ключей
    FIRST_ORDER_NUMBER и SECOND_ORDER_NUMBER, снимаются. В торговую систему
    отправляются две новые заявки, при этом изменяется только цена заявок,
    количество остается прежним;
  • Если MODE=1, то заявки с номерами, указанными после ключей
    FIRST_ORDER_NUMBER и SECOND_ORDER_NUMBER, снимаются. В торговую систему
    отправляются две новые заявки, при этом изменится как цена заявки, так и
    количество;
  • Если MODE=2, то заявки с номерами, указанными после ключей
    FIRST_ORDER_NUMBER и SECOND_ORDER_NUMBER, снимаются. Если количество
    инструментов в каждой из снятых заявок совпадает со значениями, указанными после
    FIRST_ORDER_NEW_QUANTITY и SECOND_ORDER_NEW_QUANTITY, то в торговую систему
    отправляются две новые заявки с соответствующими параметрами.
Что же тогда считается успешной одной транзакцией, если успех принятия заявок может быть различным? И, как сказал, информативности в реплае максимум наполовину. OnOrder ему не замена, он может и не прийти. В такой ситуации механизм sendTransaction(MOVE_ORDERS) + onTransReply явно недоработан. Продумайте как полноценно доносить информацию в реплае. Мое предложение - отправлять 2 реплая, с еще одним битом во флаге с указанием на какую заявку из двух каждый. Обоснуйте, почему это не будет улучшением.
MOVE_ORDERS
 
И судя по описанию происходит именно 2 транзакции на бирже. Причем может и только одна из них сработтать.
MOVE_ORDERS
 
Цитата
Roman Azarov написал:
Андрей, добрый день!

1) Можете привести пример описанного поведения? Желательно с фрагментом кода

2) SECOND_ORDER_NUMBER = nil, но для второй заявки указана цена/количество, то sendTransaction вернет соответствующую ошибку

3) Нет, только один. Это  одна  транзакция, в которой переставляются две заявки.
1) Код здесь будет лишним. Просто делаю { ACTION = "MOVE_ORDERS", MODE = '1',.. }., Ордер переставляется. А в колбеке flag имеет не праильный признак направления (покупка\продажа). За это отвечет вот такой бит (tr.flags>>17&1) у вас.Он не корректен для MOVE_ORDERS.

3) Очень странные вещи вы говорите. А как же тогда интерпретировать все поля OnTransReply(TABLE trans_reply) ? Они расчитаны на передачу данных по одному ордеру данной транзакции. Например order_num.
MOVE_ORDERS
 
А собственно ордер и не меняет ориентацию. Если цена перешагивает барьер, он просто исполняется по рынку. Так что направление в onTransReply однозначно определено.
MOVE_ORDERS
 
Пробую такие транзакции на срочном рынке в MODE=1.

1) в OnTransReply перестал работать бит, определяющие куплю или продажу - (tr.flags>>17&1). В ответе на NEW_ORDER это работает. Просьба доработать. Уверен, при перестановке цены на данном этапе уже известно, купля это или продажа. Если нет, просьба не оставлять его незаполненным, а копировать из перемещаемого ордера. Считая по умолчанию, что ордер не меняет свою "ориентацию". По умолчанию это лучше, чем пустое поле.

2) Если SECOND_ORDER_NUMBER = nil , то, по хорошему, сервер должен игнорировать SECOND_ORDER_NEW_PRICE и SECOND_ORDER_NEW_QUANTITY, даже если они заполнены. Но есть подозрение, что они могут переопределять соответствующие FIRST в этом случае.. Прошу разъяснить.

3) Если заполнены все поля FIRST и SECOND, то должно прийти 2 OnTransReply? Это вообще просто способ сократить кол-во sendTransaction, а так эти поля совершенно независимы и аналогичны 2м sendTransaction (для MODE=1)?
Получение признака "Субординированный инструмент" в lua
 
Цитата
Anton написал:
Цитата
swerg написал:
метод каким это сделано
Читается напрямую из хранилища. Вряд ли арка одобрит публикацию описаний подобного рода.

Цитата
BlaZed написал:
может откомпилите ее еще и под lua 5.4
Уже сменил локацию, теперь когда до сорцев доберусь
А может и сорцами поделитесь?
Получение признака "Субординированный инструмент" в lua
 
Цитата
s_mike@rambler.ru написал:
Цитата
Андрей написал:
 
Цитата
_sk_  написал:
 Может вы тоже подскажете, как это делается обобщенно через win32 ф-ции библиотеки w32 конкретно для стакана? Название активного окна (стакан) и выделенная в стакане строка. И как в макросе ожидать нажатие клавиш.
нужно написать свой скрипт, который рисует вам стакан (так же как это делает сам терминал), ловить действия пользователя в нем стандартными средствами и запускать нужные вам обработчики.
Но так горазда больше оверхеда по ведению онлайн еще одного стакана, хотя ф-цию нужно запускать на разовой основе. Неужели прочитать окно стакана нельзя?  
Получение признака "Субординированный инструмент" в lua
 
Цитата
_sk_ написал:
Может вы тоже подскажете, как это делается обобщенно через win32 ф-ции библиотеки w32 конкретно для стакана? Название активного окна (стакан) и выделенная в стакане строка. И как в макросе ожидать нажатие клавиш.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Sergey Gorokhov написал:
Цитата
Андрей написал:
Действительно ли могут прийти колбеки заявок других клиентов?
Конечно нет, это исключено. Только брокер может видеть заявки других клиентов.
Спасибо. Еще отвлеченный вопрос. Допустим у меня открыт стакан. Я выделяю в нем строку и хочу нажатием клавиш запустить программную обработку информации (инструмент, выделенная цена). В идеале запуском макроса, хотя запуск макросов по событиям у вас не реализован. Но как можно реализовать в следящем макросе?
Получение признака "Субординированный инструмент" в lua
 
Цитата
Sergey Gorokhov написал:
Цитата
Андрей написал:
Какой правильный формат CLIENT_CODE , если 123456/345 не работает? 345 - это доп данные  
В зависимости от настроек на стороне брокера, код клиента и комментарий могут разделяться либо "/" либо "//".
Посмотрите как оно выглядит у Вас в таблице заявок
Еще наткнулся на странное сообщение "Нужно следить за UID экземпляра QUIK, чтобы фильтровать "чужие" заявки.". Это еще актуально? Действительно ли могут прийти колбеки заявок других клиентов? Я то предполагал это поле либо 0, либо правильным..
Получение признака "Субординированный инструмент" в lua
 
Какой правильный формат CLIENT_CODE , если 123456/345 не работает? 345 - это доп данные  
Получение признака "Субординированный инструмент" в lua
 
Цитата
Sergey Gorokhov написал:
Цитата
Андрей написал:
А свои дополнения можно сделать как пишу выше, чтобы не было неразберихи. Либо =nil (отсутствуют в пришедшем ордере), либо -1, пока вы не вставите истинное значение.  
Еще раз, trans_id это наш параметр, его в принципе никогда нет в ордере. Наш сервер его проставляет, а не биржа.
Он всегда есть в OnOrder, ореде с т.з. елиента. Вы хотите сказать, что вы не можете своими внутренними признаками определить, ручной ордер или нет? Чтобы для ручных возвращать trans_id не так же, как для незаполненных. Ну исторически уже привыкли к 0 для ручных, а для незаполненных тогда просто не возвращать поле (=nil). Из ваших слов про биржу не следует, что вы не можете так формировать свои поля в OnOrder.

И насчет CLIENT_CODE в транзакции. Я его заполняю своим номером. Как его получить в OnOrder? Там нет такого поля, есть похожее по описанию brokerref, но оно не содержит моих данных, а именно /код клиента.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Sergey Gorokhov написал:
Мы не можем что-то добавить в биржевой протокол, только биржа это может.
Добавить свои собственные параметры, да можем, и UID и trans_id мы как раз и добавили.
Добавить к ним еще один? Зачем он ведь будет работать точно так же. И с ним будут точно такие же проблемы.

Приведите пожалуйста полный список полей транзакции, которые входят и в ордера и в биржевой протокол и, значит, заполнены в каждом пришедшем OnOrder.
А свои дополнения можно сделать как пишу выше, чтобы не было неразберихи. Либо =nil (отсутствуют в пришедшем ордере), либо -1, пока вы не вставите истинное значение.  
Получение признака "Субординированный инструмент" в lua
 
Цитата
Sergey Gorokhov написал:
Цитата
Андрей написал:
Повторюсь, для осмысленной обработки прихода OnOrder с trans_id=0 нужно отличать его от подобного при ручном вводе заявки.
Можете самостоятельно указать признак в комментарии, см параметр CLIENT_CODE
Цитата

20-ти символьное составное поле, может содержать код клиента и текстовый комментарий (поручение) с тем же разделителем, что и при вводе заявки вручную. Необязательный параметр
А вы уверены, что он будет проставлен в этом первом пришедшем OnOrder, в котором даже trans_id  не проставлен? Не думаю.. т.к. транзакция еще не обработана.
И в любом случае это bad design, о чем я выше пишу, когда не заполненное поле имеет значение, валидное для заполненного. И исправить это не сложно без потерь производительности, нужно сделать.
Получение признака "Субординированный инструмент" в lua
 
Это должно быть общим принципом. Приходят колбеки в процессе дозаполнения полей - ок. Но тогда обеспечьте надежный способ отличать, заполнено поле уже или нет. Незаполненное поле не должно иметь значение, валидное для заполненного.  
Получение признака "Субординированный инструмент" в lua
 
ну или особое исключение trans_id=-1 или nil, пока не заполнено, в конце концов )
Получение признака "Субординированный инструмент" в lua
 
если такого признака пока нет, можно назначить некий бит флага под это дело, например. Который =1, если trans_id имеет финальное значение. Вобщем варианты есть, чтобы не тормозить независымые потоки.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Andrey Bezrukov написал:

Кроме того, поскольку параметры trans_id и uid на заявке доступны из скрипта - уже сейчас можно реализовать необходимую логику, которая будет выполнять или пропускать соответствующий блок скрипта в зависимости от того, равен ли trans_id нулю или нет при очередном срабатывании OnOrder.
Повторюсь, для осмысленной обработки прихода OnOrder с trans_id=0 нужно отличать его от подобного при ручном вводе заявки. Тогда обеспечьте такую возможность по какому-то иному признаку. Чтобы точно понимать, что этот приход - не от ручной заявки, а от некоей транзакции в процессе заполнения trans_id.
Получение признака "Субординированный инструмент" в lua
 
Так он становится неотличим от заявки, которую вводишь руками. Поэтому давайте все же зарегестрируем пожелание, чтобы onOrder не рассылался раньше, чем на сервере обработается в полной мере транзакция, назначится trans_id. И все пришедшие ОnOrder будут с верными trans_id (как и order_num). А уж какие-то прочие поля можно досылать потом.
Получение признака "Субординированный инструмент" в lua
 
Потому как без trans_id обрабатывать его осмысленно невозможно. Это не хорошо.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Andrey Bezrukov написал:
Так, например, при выставлении заявки – OnOrder будет вызван при получении заявки (в результат её успешной регистрации в ТС), так и при её снятии/исполнении.
Добавлю еще по этому поводу. Иногда, редко, OnOrder по созданию заявки приходит еще один самый первый раз, даже раньше OnTransReply, причем с trans_id=0. Речь про заявки из макроса, которым я назначаю trans_id. Как говорилось ранее, да, OnOrder дублируется несколько раз после OnTransReply. С изменениями в поле uid кажется. Но вот такое, что он приходит еще раз раньше OnTransReply.. не ожидано было. Не ошибка ли?
Timer Resolution и sleep(1)
 
Цитата
rst9 написал:
скорее всего, вы используете какую-то стороннюю lua-библиотеку, которая инициализирует mm-таймер для данного процесса. и он остается до тех пор, пока не перезапустите квик. не обязательно это делается напрямую, может быть связано, например, с проигрыванием аудио.
О, действительно. После вызова w32.mciSendString sleep(1) работает 1.97мс..
Что ж, тогда вопрос разработчикам, может стоить сделать этот механизм штатно управляемым? Штатно значит всегда работает не менее 15.6мс..
Timer Resolution и sleep(1)
 
Добрый день!
Иногда sleep(1) стабильно работает 15.5мс, иногда ~1.5мс.
Понятно, что это связано с системным Timer Resolution. Причем в последних сборках это не глобальная настройка, менять надо из самого процесса
https://habr.com/ru/post/522212/
Значит вы как-то переключаетесь в квике между частотами.с помощью ф-ции NtSetTimerResolution
Как нам этим управлять и получать желаемую частоту? Видимо нужна еще одна сервисная ф-ция.
Все же поведение sleep(1) должно быть более предсказуемым, чем разброс на порядок на незагруженной системе.
Количество открытых позиций (ОИ)
 
А так же добавить возможность его получения, например, через DataSource после CreateDataSource. В т.ч. через колбек.
Количество открытых позиций (ОИ)
 
Цитата
Andrey Bezrukov написал:
Здравствуйте.
Открытый интерес, или график количества открытых позиций по инструменту доступен для инструментов срочного рынка.
Для того, чтобы построить график количества открытых позиций надо  пройти в пункт меню  Создать окно / Графики …   Выбрать интересующий Вас инструмент срочного рынка , нажать кнопку  «Изменить» . В Появившемся окне выбрать пункт  «История значений параметра»  и выбрать параметр  «Количество открытых позиций» .  Подтвердить создание окна.
В этом случае Вы построите график открытого интереса в отдельном окне. Если Вас интересует возможность добавления аналогичного графика в окно с другим графиков, то для этого выполните следующие инструкции.
Щёлкните правой кнопкой мыши по области построения в окне графика, куда Вы хотели бы добавить новый график и выберите пункт  «Добавить график (индикатор)» . В появившемся окне укажите новый источник данных.
Установите или снимите флаг  «Поместить график в новую область» . Подтвердите добавление графика.
Добрый день!
В новых версиях Quik ОИ есть в таблице обезличенных сделок. Как теперь его оттуда (а не из историй параметров) вывести на график? Который так же строится по таблице обезличенных сделок.Если это не возможно, прошу добавить функционал.
Получение признака "Субординированный инструмент" в lua
 
Прежде прошу привести пример существующего способа экспорта по DDE в самый простой общедоступный получатель данных, помимо Excel. Попробовал в OpenOffice кстати, не работает. Либо что нужно указать в настройках вывода.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Roman Azarov написал:
Андрей,

Цитата
Андрей написал:
Да, речь про параметр таблицы текущих торгов.
В данном случае, повторимся, можно посмотреть  название    данного параметра воспользовавшись экспортом по DDE, а затем, при помощи данного названия, получить значение параметра при помощи функции getParamEx().
А если Excel нет? Как вывести в csv файл, например? Или еще что-либо открыто доступное. В документации тема не раскрыта, все на примере Excel.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Roman Azarov написал:
Андрей, добрый день!

Если данный признак (поле) не описан в документации, значит получить его нельзя.
Если же речь идет о параметре таблицы текущих торгов, можно воспользоваться экспортом по DDE с включенной опцией "Формальные заголовки", чтобы посмотреть наименование параметра.
Да, речь про параметр таблицы текущих торгов. Задача не посмотреть его, а получить доступ в макросе, как к одному из статичных параметров инструмента. Он скорее ведь не относится к текущим торгам. Рассмотрите тогда возможность расширить таблицу securities этим и, возможно, еще какими-либо статичными параметрами инструментов. Кторые выводятся сейчас в интерфейс ТТТ.
Ошибка управления стоп-заявкой на графике
 
Извините, надо было не в этой ветке создать. Просьба переместить.
Ошибка управления стоп-заявкой на графике
 
Для стоп заявок с условием цены "по другому инструменту" на графике этого другого инструмента появляется эта заявка и ее можно перемещать мышью.
Это хорошо. Плохо то, что по ошибке шагом перемещения является шаг цены того основного инструмента, а не этого, по которому условие.
Получение признака "Субординированный инструмент" в lua
 
Как получить?
В таблице securities отсутствует.
Страницы: 1
Наверх