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

Есть проблемы с переносом конфигураций с более ранних версий QUIK на 7.1.0.381: при работе на мониторах с разным разрешением: размеры окон зависят от разрешения экрана:

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

Вот такой код:
Появляется скрол:

хотя высоты хватает:

В QUIK v.7.1.0.381 как-то так:

Верните размер окна обратно или сделайте его редактируемым.

Imersio Arrigo,
Стакан, где-то были ещё темы и с ТТП.

Мои суждения основываются на той "информации", которую вы "предоставляете".
Если для событий OnQuote действительно не создаётся очереди на сервере, то об этом так и надо было сразу сказать, и закрыли бы тему сразу.

Другими словами, отсутствовать может любой из параметров, относящийся к связанной заявке?
Т.о., заглянув в таблицы заявок и стоп-заявок, мы можем не обнаружить связанных заявок просто потому, что у стоп-заявки ещё не обновился параметр co_order_num?

Вопрос был в другом: какие поля могут быть незаполненными в первом колбэке?

Я сейчас задаю вопрос, чтобы знать, какую логику закладывать при работе с данным видом колбэков, чтобы потом не было "сюрпризов".
Называйте это "любопытством" или как хотите.

Вот я действительно не понимаю: если очередь не отправленных событий OnQuote создаётся на сервере, то кто мешает в этой очереди держать только одно последнее событие, а все предыдущие удалять?

Вы щас прикалываетесь? Мол, мы чё-то сделали, предлагаем вам самостоятельно потестировать и разобраться, как оно работает.
Впрочем, при выпусках новых версий явно используется этот подход.

Очевидные ситуации не требуют рассмотрения.
Если стоп-заявка подавалась с указанием trans_id, то может ли колбэк OnStopOrder прийти с незаполненным параметром trans_id?
На всякий случай напомню, что по заявке типа "Со связ. заявкой" приходят два колбэка OnStopOrder. Обычно они одинаковые. Но могут ли чем-то отличаться?

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

Кстати, уже было такое пожелание несколько лет назад:

5. При подстановке цены и объёма, если в "Настройках - Торговля" задано значение количества лотов по-умолчанию, то брать его.

Да что ж такое...
ЛКМ = покупка
ПКМ = продажа
по цене той строки, куда кликнули.
Всё. Больше никаких условий. Цвет поля, куда кликнули роли не играет.

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

Эээ... Может, так: левая - покупка, правая - продажа по цене, куда кликнули. А по зелёному или красному - по барабану. Лимитка или рынок - зависит от цены, куда кликнули. ?

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

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

Согласен. Но как быть с разряженным стаканом, где есть область спрэда?

Для событий OnStopOrder параметры trans_id и uid могут прийти незаполненными?

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

Планируете ли вы добавить в терминал трансляцию значений границ диапазона цен, установленного брокером?

ACTION=KILL_STOP_ORDER, STOP_ORDER_KEY=7245883

Есть большая разница в том получили ли мы значение параметра и оно равно нулю или значение параметра ещё не получено.
Аргументы я уже приводил в этой теме: ситуации, когда значение параметра может читаться двояко.
Нельзя при получении trans_id=0 выполнить сначала одно действие, а потом, когда через минуту придёт trans_id=67890 переиграть всё обратно.
Тоже касается и других таблиц: QUIK вам показывает ноль, когда в действительности с биржи ничего не пришло, что зачастую вносит путаницу.

Замените на t.trans_id ~= nil and t.trans_id>0, и скрипт вылетать не будет  

По какому принципу отсылаются данные клиенту из образовавшейся очереди? Клиент передаёт серверу, что предыдущие данные им успешно получены? Или как?

up
Сделайте возможным читать архив графиков из индикаторов без необходимости открывать окна этих графиков.

1. Гарантированно ли при изменении лимита в системе всегда уже есть информация по заявке (сделке), вызвавшей его (лимита) изменение?
2. При постановке (исполнении) нескольких заявок подряд зачастую лимит может измениться только один раз.  

Бинго!
Откройте таблицу Позиций по клиентским счетам (фьючерсы). Там много всяких параметров. Так вот OnFuturesClientHolding будет вызываться при изменении любого параметра (даже если никакая позиция не открыта): поставили вы заявку на покупку/продажу - получите колбэк, заяка исполнилась - ещё колбэк, вариационка - ещё колбэк и т.д.

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

Ещё раз: указав число строк, заведомо больше, чем до max/min возможной цены, вы ничего не потеряете. Для того же Si будете видеть полный стакан, который даёт вам брокер. Но для менее ликвидных инструментов, квику не придётся рисовать стакан в несколько тысяч строк.

Firestorm,
К примеру, вы хотите работать в разряженном стакане, но из-за малого числа заявок вблизи спрэда и нереально высокими и низкими ценами дальних заявок терминал вынужден вам рисовать стакан в несколько тысяч строк.
Ограничив количество отображаемых строк (150-300 в обе стороны вам ведь будет достаточно?), вы сохраните ресурсы компьютера, не потеряв при этом полезной информации.

Firestorm,
Откройте какой-нить опцион в дальнем страйке  

Индекс элементов в таблице начинается с 0.
Соответственно, последний элемент имеет индексСтранно, что раньше у вас всё работало...

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

Сделайте возможным использование функции CreateDataSource из индикаторов.

Эффективная цена позиций (данные из таблицы getNumberOf('futures_client_holding') меняется на цену последней сделки каждый клиринг (и в дневной тоже).

Кстати, функция T() возвращает время тика без поля count, хотя в документации QLUA указано:

Уже. Вот только добавление/изменение параметров индикатора занимает достаточно много времени, в течение которого терминал оказывается в "подвешенном" состоянии.

Здравствуйте.

Сделайте возможным на тиковом графике выделять разным цветом объёмы покупок и продаж.

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

#15 ?

 

Возможно, в этой теме найдёте что-то полезное для себя: CreateDataSource

Понятно, значит, просто перестраховались  

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

Это пожелание считается уже полностью реализованным ("Глубина стакана") или будет доделано для разряженного стакана?

Вместо nil я вижу дефолтные квиковские ""/0. Очевидно, ошибка в коде терминала, а не документации  

Вот такую ошибку выдаёт при попытке переставить заявки на разных счетах:
Нужны какие-то особые права?

Отдельный ответ с биржи?

3. Подать одну транзакцию на перестановку двух заявок по разным счетам нельзя. А, значит, и параметр account будет совпадать.
Точка.
Поручение (транзакция "MOVE_ORDERS" на перемещение) для обеих заявок одно. А, значит, и параметр brokerref будет совпадать.

Так понятно?

Ох, нелегкая это работа...
Егор,

1. nil я понимаю буквально, как nil. В программировании это выглядит так:
Поэтому и уточнил:

2. Ваш ответ #12 можно расценить, как дешёвую отмазку, чтобы не заниматься проблемой.

3. Подать одну транзакцию на перестановку двух заявок по разным счетам нельзя. Поручение для обеих заявок одно.
   А, значит, и параметры account и brokerref будут совпадать. Не вижу никаких причин, чтобы не заполнить эти параметры в OnTransReply.

4. При любом исходе ответ на транзакцию один: либо сразу обе заявки переставлены, либо нет.
  А, значит, нет необходимости дублировать OnTransReply.

Одной транзакцией можно переставить две заявки по разным счетам (читай: с разными account)?
Сколько у вас приходит ответов OnTransReply при перестановке сразу двух заявок? У меня две? Смысл в двух абсолютно одинаковых OnTransReply?

Заявки, переставляемые транзакцией "MOVE_ORDERS", таскают за собой параметр brokerref от самой первой заявки. Это нормальная ситуация?

Для транзакций "MOVE_ORDERS" всегда возвращается OnTransReply с пустой строкой в качестве параметров account и brokerref

Подытожим. Таким образом, OnTransReply с status = 3 (и только три) означает, что транзакция выполнена.
Остальные значения статуса говорят о том, что транзакция не выполнена (и не будет выполнена). Так?

Приведите, пожалуйста, полный и исчерпывающий список возможных вариантов значений параметра status для колбэка OnTransReply.
Из-за отсутствия этого списка для QLUA нам и вам (сотрудникам техподдержки) приходилось пользоваться аналогом этого списка для формата .tro-файла, что зачастую приводило к неверным рекомендациям с вашей стороны относительно параметра status.