Дмитрий пишет: Я понял. Есть какая-нибудь инструкция как использовать файл Swetchi.qpl для моих целей? Как его интегрировать с Квиком? Спасибо.
Перед использованием, QPILE портфель требуется настроить Настройки указываются в самом qpl файле Этот файл можно открыть любым текстовым редактором, например блокнотом.
Инструкции по работе с QPILE портфелями приведены в стандартной документации на терминал QUIK (клавиша F1) -Раздел 8. Алгоритмический язык QPILE --Работа с таблицами QPILE ---Загрузка программы
Дмитрий пишет: Интересуют именно те данные, что отображаются в данный момент на графике, прежде всего на дневках.
Дело в том что в таблицу текущих значений данные попадают срезами (раз в период) а на график они попадают из таблицы обезличенных сделок (то есть без пропусков) поэтому в какие то моменты показания действительно могут отличаться. К сожалению через интерфейс нельзя экспортировать текущие данные с графиков. Вопрос можно решить через языки программирования Qpile или QLUA На нашем сайте есть примеры: http://arqatech.com/upload/iblock/c9f/qpile.zip среди них есть пример Swetchi.qpl который выводит таблицу содержащую свечи, можно использовать его
Что касается проверки на сервере QUIK: Есть отдельные FIX решения для претрейда о них мы сейчас говорить не будем, так как эти продукты специфичны. На сервере QUIK есть своя встроенная проверка. По умолчанию проверка на сервере отключена. Проверяется частота транзакций в секунду на каждого отдельного пользователя. Проверяются все транзакции пользователей типа "Новая заявка". В количестве разрешенных транзакций будут учтены только те транзакции, которые прошли FloodControl. Не прошедшие его учитываться не будут. Если Ваша транзакция прошла наш FloodControl, но ее отвергла биржа, то такая транзакция попадет в счетчик. Какая частота настроена у каждого конкретного брокера нам не известно. Пример: Если пользователь за раз подает 100 транзакций а на севере разрешено только 10, то это означает что первые 10 транзакций пройдут, а последующие будут отвергнуты.
Текст ошибки в случае нарушения ограничения, будет следующим: "Количество транзакций превышает максимально разрешённое <число> в секунду."
Что касается проверки на стороне биржи, рекомендуем уточнить у специалистов биржи.
Николай Камынин пишет: 1000 заявок в секунду по разным инструментам и разным счетам да еще через терминал КВИК? Так Вы ж, батенька, фантазер!!! Для начала попробуйте хотя бы 100 отправить.
Николай, на ежегодном нагрузочном тестировании отправляется в разы больше.
Антонио пишет: И нормально работает. Только вот Комментарий более 20 символов не прошёл, потому и возник вопрос.
Вы приводите пример формальных заголовков, а я говорю про пример обычных. Это намного разные вещи. Формальные заголовки соответствуют полям в форме ввода заявки, а обычные соответствуют документации.
Цитата
Антонио пишет: Там QLUA.chmи Интерпретатор языка Lua.pdf- в них про 20 символов ничего нет.
Даже более того там вообще нет ничего про параметры транзакций, просто потому что параметры транзакций описаны в info.chm
Здравствуйте, В транзакции указывается не brokerref а CLIENT_CODE Согласно документации: CLIENT_CODE - 20-ти символьное составное поле, может содержать код клиента и текстовый комментарий с тем же разделителем, что и при вводе заявки вручную. Параметр используется только для групповых транзакций. Необязательный параметр
Sergey Gorokhov пишет: Здравствуйте, С недавних пор таблица сделок стала обновляемой, в результате это означает что на одну сделку может приехать несколько колбэков. Вопрос уже плотно обсуждался на нашем форуме OnTrade
Позже я прочел эту тему, но так и не понял как быть.. что же прописать в коде чтобы исключить дублирование?
Здравствуйте, С недавних пор таблица сделок стала обновляемой, в результате это означает что на одну сделку может приехать несколько колбэков. Вопрос уже плотно обсуждался на нашем форуме OnTrade
Здравствуйте, При отправке большого количества транзакций сервер не будет делить их на порции а отправит как есть. Далее транзакции будут отвергнуты и клиенту придет соответственная ошибка.
Решать вопрос нужно между клиентом и брокером, даже если сервер находится у нас. Ибо сервер принадлежит не нам, хоть и находится в наших дата центрах.
тот самый пишет: если так? то, информация должна быть от вас.
Даже если сервер находится у нас, мы не имеем права разглашать информацию касающуюся брокера без его прямого согласия. Так как это нарушение коммерческой тайны. На все вопросы по услугам брокера должен отвечать только брокер.
Да Close() не удаляет параметр из списков. Такова текущая реализация. Ранее мы уже регистрировали от другого пользователя пожелание по данной теме. Можем зарегистрировать еще одно от Вас.
Юрий пишет: Здравствуйте, торгую у брокера БКС, после обновления квика до седьмой версии из терминала исчезли такие функции как - таблицы- портфели- настройка портфелей- просмотр портфелей. в своей торговле использую робота «Stop & Profit» для автоматического выставления стопа и профита, при его настройке используются -( портфели- настройка портфелей- просмотр портфелей.), подскажите пожалуйста где мне найти данные функции в новой версии квика ?
Здравствуйте, В 7 версии изменилось меню программы Новое меню В частности, QPILE теперь находится по адресу Сервисы / QPILE скрипты…
Дмитрий пишет: Уважаемые разработчики, сегодня обнаружил ошибку в работе обновленной версии вашей утилиты QMinEditor.exe (кстати, путем обратной конвертации полученных с ее помощью текстовых файлов в двоичный формат, который вы так и не захотели опубликовать). Ошибка заключается в следующем: если в двоичном файле с данными графика есть свечи, где цена отрицательная (меньше 0), то в текстовый файл вместо нее выводится 0. Отрицательные цены встречаются по инструментам типа "спред" (класс FUTSPREAD) - посмотрите, например, минутные интервалы по спредам GZH5GZM5 и RIM5RIU5.
Добрый день,
Ошибка в QMinEditor, из-за которой отрицательные цены конвертировались в 0, исправлена в версии программы, которая вошла в дистрибутив сервера QUIK версии 5.1.3.
Приносим Вам свои извинения за доставленные неудобства.
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Viktor MMM пишет: По мне так все понятно излагает Старатель. И так же понятно, что Сергей Горохов в данном случае на вопрос не отвечает. Для убедительности теперь и мне, наверное, нужно цитат добавить пачку? Сергей, бывает подклинивает всех. Я - не исключение, Вы - тоже. Ваши коллеги решили Вас одного оставить разбираться с этой темой? Это повинность такая? Чтобы потом пользователи не стали сравнивать слова Вас и Вашего коллеги?
На все вопросы ответы уже были, на главный вопрос темы топика, а именно в каких случаях trans_id может не доехать, ответ уже давался не однократно, а именно по моим скромным подсчетам уже раз пять. Если есть что-то конкретное спрашивайте.
Цитата
Viktor MMM пишет: Проясните уже, наконец, про nil и 0. Хоть кто-нибудь. Можно инкогнито)
Про nil, его нет и не было, мы зарегистрировали пожелание. Дословно оно звучит так "чтобы во всех колбеках возвращающих таблицы, при отсутствии значения параметра передавать nil вместо "0"
Про "0", конкретно в trans_id. Сейчас для trans_id значение "0" является значением "по умолчанию" Это значит что если он не задан, приедет "0" Если он задан, но по каким-то причинам не доехал, то с начала приедет "0" а потом правильное число. Случаи когда он может не доехать озвучивались ранее. 1) сбой на сервере 2) когда сделка приехала раньше ответа на транзакцию.
Ув. Старатель, обращает внимание на то что в такой реализации, нет 100% уверенности что сделка приехавшая с trans_id=0 выставлена через интерфейс терминала, так как позже может приехать trans_id=число. Да сейчас это действительно так и способ решить проблему уже озвучивался "используйте комментарий" Далее, предлагается разделить понятия nil и 0, а именно в базе записывать "0" (как сейчас) а в описанных выше случаях, при приезде сделки отправлять клиенту nil и далее делать поиск правильного trans_id. На что не однократно прозвучал ответ, что в такой реализации для отправки trans_id=0 будет лишний колбэк, которого сейчас нет. А лишние колбэки, судя по этой ветке форума, никому не нравятся. Соответственно мы предлагаем зарегистрировать пожелание в общих терминах, без озвученной конкретики и подумать над альтернативным решением, каким именно пока не понятно.
Старатель пишет: Мне не понятны ваши трактовки "частный"/"общий" случай.
Давайте попробуем определиться: "Общий случай" - обычная рабочая ситуация "Частный случай" - ситуация с исключительными параметрами, которые редко (или крайне маловероятно) проявляются в обычной работе. "Сбой сервера" - непредвиденный рестарт сервера, предварительно вызванный какими-либо проблемами. В зависимости от характера проблем последствия могут быть не предсказуемы.
Цитата
Старатель пишет: Является ли следующая ситуация сбоем на сервере: когда "сделка приехала раньше ответа на транзакцию" и в этом случае в первом колбеке trans_id=0 даже, если транзакция была подана не через интерфейс ?
Данная ситуация не является сбоем, это "частный случай" Да, в этом случае первым приедет trans_id=0 даже, если транзакция была подана не через интерфейс. Так как trans_id (и UID тоже) хранится на записи об ответе на транзакцию. При получении ответа на транзакцию, сервер повторно отправит сделку с заполненным trans_id.
Sergey Gorokhov пишет: Мы можем зарегистрировать пожелание "отличать сделки порожденные транзакцией выставленной через интерфейс от выставленной через Lua" без конкретики озвученной в Вашем предложении. Устроит такой вариант закрытия темы?
Как меня может устроить такой вариант, если в вашем предложении нет никакой конкретики? И потом, почему обязательно Lua? Сервер знает, что транзакция подана через Lua, а не Api или QPILE?
Речь действительно не только про Lua, просто так проще передать мысль
Старатель пишет: Таким образом, теперь вы сами опровергаете свои же слова о повторной приходе колбека OnTrade необходимостью отправлять дополнительные параметры, в частности uid и trans_id ?
Не вижу противоречий, Вы спрашивали конкретно про trans_id, я Вам ответил конкретно про trans_id. В посте на который Вы ссылались речь была не только про trans_id.
Цитата
Старатель пишет: Может ли в штатной ситуации trans_id прийти незаполненным (в текущей реализации это означает ноль) в первом колбеке?
Конкретно про trans_id да может приехать 0, в случае когда заявка выставлялась через интерфейс. Если говорить про случай когда заявка выставлялась через LUA, то в общем случае trans_id в штатной ситуации он приезжает заполненный.
Цитата
Старатель пишет: На всякий случай, привожу ссылку на ответ более компетентного сотрудника, как это работает в 6-й версии: OnOrder без UID
Частный случай когда сделка приехала раньше ответа на транзакцию тоже возможен.
Мы можем зарегистрировать пожелание "отличать сделки порожденные транзакцией выставленной через интерфейс от выставленной через Lua" без конкретики озвученной в Вашем предложении. Устроит такой вариант закрытия темы?
Старатель пишет: OnTrade всегда приходит с заполненным полем trans_id?
Нет не всегда, в частности из-за сбоя на сервере может приехать 0, а потом правильный trans_id или он может вообще не приехать.
Цитата
Старатель пишет: Если trans_id=0 в сделке, означает ли это, что сделка была совершена вручную?
В общем случае да, в частном см. выше.
Цитата
Старатель пишет: Цитата Старатель пишет: Далее, когда сделка приезжает на сервер, в общем случае отправлять её клиенту, раз уж транзакцию ещё не нашли, без проставленного параметра . А когда транзакция найдётся, то проставить найденное значение параметра . И там будет либо номер транзакции либо честный ноль .
В случае когда транзакция была отправлена через терминал, в частном случае это означает что сервер будет отправлять лишний колбэк.
Старатель пишет: Я же предлагаю при получении транзакции от клиента сохранить эту транзакцию с trans_id , если его не было, со значением "по-умолчанию" = 0 .
Сейчас ровно так и работает
Цитата
Старатель пишет: Далее, когда сделка приезжает на сервер, в общем случае отправлять её клиенту, раз уж транзакцию ещё не нашли, без проставленного параметра .
Это частный случай, который в общем маловероятен (проверьте сами) из-за которого в этой ветке весь сыр бор. Допустим, как уже было сказано приехала сделка. И мы знаем что эта сделка была выставлена через интерфейс С Ваших слов сервер отправил ее клиенту с trans_id=nil Далее, поиск по базе, он нашел транзакцию и еще раз отправил trans_id=0 Итого, опять будет лишняя отправка.
Вот это
Цитата
Старатель пишет: При отправке колбеков с сервера на терминал trans_id=0 можно использовать для обозначения, что данный параметр проставлен. Если параметр не проставлен, то он = nil .
Противоречит Вот этому
Цитата
Старатель пишет: Я же предлагаю при получении транзакции от клиента сохранить эту транзакцию с trans_id , если его не было, со значением "по-умолчанию" = 0 .
Старатель пишет: Я же предлагаю при получении транзакции от клиента сохранить эту транзакцию с trans_id, если его не было, со значением "по-умолчанию" = 0. Далее, когда сделка приезжает на сервер, в общем случае отправлять её клиенту, раз уж транзакцию ещё не нашли, без проставленного параметра.
Сейчас оно так и работает.
Цитата
Старатель пишет: Вы даёте крайне противоречивую информацию в своих сообщениях: во втором случае, вы не указываете, что trans_id может отправляться несколько раз.
Здравствуйте, Интервал в 1 секунду, для стаканов является параметром по умолчанию. Его также можно задать вручную, внеся изменения в файл info.ini. секция [excel], параметр price-timeout. Если этой секции нет внесите её [excel] price-timeout=90 Минимальное значение 10. Параметр измеряется в миллисекундах.
Еще раз, более подробно [QUOTE][USER=54]Старатель[/USER] пишет: При отправке колбеков с сервера на терминал trans_id=0 можно использовать для обозначения, что данный параметр проставлен. Если параметр не проставлен, то он = nil . [/QUOTE]
Как это будет работать по Вашему предложению: Допустим отправили транзакцию через LUA
На сервер приехала сделка. trans_id не биржевой параметр, а значит сделка приезжает без него. Как следствие, сервер не знает заявка которая привела к сделке выставлена через интерфейс или через Lua. Поэтому он не может сразу определить что послать клиенту trans_id=0 или trans_id=nil или trans_id=число
Согласно Вашей логике, сервер должен как то узнать что сделка была выставлена через Lua и отправить клиенту trans_id=0 Чтобы это сделать, сервер ищет транзакцию которая привела к выставлению заявки. Допустим он ее нашел и выяснил, что на транзакции есть trans_id, а значит согласно Вашей логике он должен отправить trans_id=0 А потом он еще раз должен отправить уже trans_id=число. То есть серверу придется два раза отправить клиенту сделку
Сейчас работает так: Приехала сделка. Сервер ищет транзакцию Он ее нашел и выяснил что на транзакции есть trans_id и отправляет сделку клиенту с проставленным trans_id. Если на транзакции нет trans_id он отправляет "0"
О том и речь, что на один и тот же вопрос было уже три ответа.
Цитата
Старатель пишет: " Нет " - означает "нет, нельзя рассчитывать "? Или что "параметры сделки останутся неизменными "?
Это уже четвертый раз когда Вы задаете все тот же вопрос, на который все тот же ответ. Еще раз повторяю:
Цитата
в случае сбоя на стороне сервера, есть вероятность что сделка может приехать без UID и без trans_id
Цитата
Старатель пишет: 1) Дать исчерпывающий список обновляемых параметров.
нет.
Цитата
Старатель пишет: 2) Внести изменения в ПО таким образом, чтобы все отсутствующие параметры имели значение nil (это касается не только OnTrade).
Вы опять повторяетесь, на это уже был ответ.
Цитата
Пожелание зарегистрировали.
Цитата
Старатель пишет: 3) Для параметра trans_id внести изменения таким образом, чтобы для транзакций, заявок, сделок без "Идентификатора транзакции" значением по-умолчанию был 0 . Если значение параметра ещё не определено, то соответственно - nil .
И снова Вы повторяетесь, на это уже был ответ
Цитата
Вы же предлагаете чтобы сервер делал одну и ту же работу два раза. первый раз он будет искать транзакцию по сделке чтобы проставить trans_id=0 а второй раз чтобы проставить правильный trans_id масло масленое получается.