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

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

Данную проблему поднимал почти год назад: Архив графиков.
Проблема в том, что на сервере QUIK нет никакого контроля качества принимаемой информации. И, если в результате какого-либо сбоя на одном из узлов передачи данных между шлюзом биржи и сервером QUIK часть данных "потеряется", то это так и останется незаметным для сотрудников брокера, пока (и если) кто-нибудь из бдительных пользователей не сообщит им об этом.
Проблема отсутствия части сделок в ТВС, и как следствие - части данных на графиках, - явление не редкое: по одному только инструменту более 2% в год.  

Можно, но есть множество причин, по которым данный вариант не является надёжным.
Поэтому давайте сделаем так, чтобы не нужно было гадать: есть данные - транслируем, нет данных - не транслируем.
Спасибо.

Очевидно, что, когда принималось решение о такой подставе замене, должно было предусмотреть вариант чтения текущей позиции.
Поделитесь, пожалуйста, решением однозначного определения текущей позиции по инструменту, в случае, когда мы видим в таблице ноль. Ну, т.е., по каким признакам можно понять, что размер позиции ещё не определён и нужно ждать колбэка?

Почему при добавлении в новую таблицу key должен быть равен -1?
Что произойдёт, если добавлять в новую таблицу с другим, отличным от -1, значением?

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

Вот конкретный пример, который у вас будет воспроизводиться всегда:
Получаем текущие позиции из таблицы futures_client_holding:
Затем в 18:45:20 приходит колбек
Это биржа шлёт эти нули или QUIK сам их подставляет?

Иногда, например во время клиринга, в таблицах QUIK транслируются нули вместо реальных позиций.
Эти нули присылает биржа или QUIK сам подставляет их вместо null?

Как можно понять, когда там действительно нули, а когда позиции пока ещё не загружены?

Там вы ответили о другом.

Эко вы завернули      Понятно, что для использования в личных целях вы не можете ничего запретить.
Здесь же я спрашиваю, могу ли я или кто-то другой по аналогии написать скрипт, который будет выполнять функции, до которых у ваших программистов не доходят руки (и не скоро, наверное дойдут).
К примеру, при старте QUIK (или по нажатию "горячих клавиш") открывать окно "Доступные скрипты" (или управлять другими окнами) и свободно распространять его на просторах интернета?

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

Прокомментируйте, пожалуйста, следующую ситуацию:

Как можно однозначно определить к какой секции относится тот или иной счёт: фондовой, срочной, валютной?

Спасибо за ваше "расследование", но тема соответствия номера параметра trdacc_type строковому описанию не раскрыта.
Полагаю, справедливо было бы предоставить слово представителям компании разработчика.

Или хотя бы сохранение состояния и позиции окна в файле настроек  

А что за ошибка "Неверная версия протокола"?
У брокера сервер QUIK ниже версии 5.0?

А, всё понял: вы взяли из pdf, а я из chm,
Ну и что можно сказать, если даже в самом Руководстве пользователя QUIK информация разная?

Откуда вы взяли эту таблицу?
У меня другая таблица (из того же Руководства, Раздел 5):
Только порядок перечисления строковых значений не соответствует числовым значениям параметра trdacc_type таблицы trade_accounts.
Нужно именно однозначное соответствие.

Где можно подробнее узнать о значениях этого параметра?

Это говорит только о производительности рабочего места  
Далее появляется объект с неизвестными нам свойствами в виде трассы до сервера QUIK, который не позволяет сделать каких-либо объективных выводов о производительности самого сервера, поскольку не известно, с какой частотой эти транзакции попадали к нему на обработку.

Это результат в моменты низкой активности на тестовом контуре. Во время более активных периодов результат хуже: менее 100 заявок в сек.

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

Если речь именно про транзакции, то отправить их можно более 1000 в секунду.
Так на тестовом QUIK я отправлял 12-14 тыс. транзакций за одну секунду.
Другое дело, что заявки по ним выставляются в течение нескольких секунд. А ответ по всем транзакциям приходит так вообще в течение более минуты.

Давайте зарегистрируем.
А то в текущем виде смысла нету в :Close(). Это с таким же успехом можно просто удалить сам объект ds = nil.

При включённой настройке "Исходя из настроек открытых пользователем таблиц" функция CreateDataSource добавляет параметр в списки принимаемых параметров.
Метод :Close() не удаляет этот параметр из списков. Таким образом, :Close() не влияет на возможность получения данных при работе с ними через getParamEx.

Это нормальная ситуация?

Разговор не про "Карман транзакций"

Работает. Но эту комбинацию вы помните, я помню. А кто-то никогда и не пользовался горячими клавишами.
Пункт меню всё же не будет лишним  

Не нашёл в меню "Выполнить транзакцию"

Если происходит "переворот" позиции, то также блокируются средства на сумму отрицательной вариационной маржи по закрываемой позиции:
http://forum.moex.com/viewtopic.asp?t=30125

Такой вариант не подходит: в настройках не установлено "Добавлять новую бумагу во все таблицы"
Понял, спасибо. Надеюсь доделаете.

Сама os.execute вызывает окно командной строки, которое вылазит на первый план и, если, к примеру, вы работаете в полноэкранном приложении, норовит его свернуть.

Именно, с учётом "ленивого" правильного вычисления это выражение является корректным.
Зачем? Любой код бумаги подставляете.

Вот так выглядит таблица, возвращаемая getParamEx, если искомый параметр ("tradingstatus") не задан в списках:
А вот так, если параметр получен:

Спасибо.
В техподдержку-то я не догадался заглянуть: искал в "Продукты и услуги - QUIK"

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

Вот такой код:
выводит "0.000000".
Но мы уже наученные - понимаем, что ноль в QUIK - это не всегда ноль. Проверяем тип данных, чтобы не был равен 0:
выводит 2.
Вроде, нормально. Ан, нет: для параметра "tradingstatus" тип должен быть 4. Значит данный параметр Квиком не получен. И так для многих параметров.

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

Оказывается, связаны.
Если включена настройка "Исходя из настроек открытых пользователем таблиц", то CreateDataSource автоматически добавляет бумагу/параметр в список получаемых параметров.

Таким образом, с помощью getParamEx можно будет получить значения параметров. (Выше я был не прав: CreateDataSource всё же не совсем бесполезна в этой ситуации).

Правда, ds:Close() бумагу уже не из списка не удаляет.

Добрый день.
В руководстве QLua к QUIK v.7 добавилось описание функции OnConnected, из которого стало ясно, что колбэк, вызываемый при получении нового класса уже существует.
Есть ли колбек, вызываемый при получении новой бумаги в существующем классе?

Дайте, пожалуйста, ссылку на страницу со списком дистрибутивов программы, утилит, библиотек, справочных руководств...
А то на сайте заблудился...

Я бы уточнил: как 0 (ноль), так и "" (пустая строка) - оба значения сейчас могут трактоваться двусмысленно.

Вот в случае этой реализации и может возникнуть дополнительный колбэк, в зависимости от текущей реализации.
Если сейчас после колбэка со значением <0 = null (параметра нет)> не отправляется повторный колбэк со значением <0 = 0 (параметр заполнен)>, то при реализации указанного выше предложения будет возникать дополнительный колбэк.



Уже писал, что часто - это не выход из положения:

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



А какая нам теперь разница, сколько колбэков обрабатывать: 3 или 4 или сколько там будет?
Для нас важно чёткое понимание получили ли мы интересующие нас данные или ещё нет.

CreateDataSource(), SetUpdateCallback(), T()
Принцип тот же: время последнего события больше предыдущего.

Отметите это в документации?
Спасибо.
Тогда надо смотреть datetime у OnOrder

Сервера QUIK или биржевое?

Так какого вы мне тут расписываете на 3-х страницах?!

Я вам говорю, что получив колбек с trans_id=0 (сюда можно вписать название любого другого обновляемого параметра), я не могу быть уверенным, что значением этого параметра действительно является 0 (ноль).
И меня (думаю и других пользователей QUIK) не волнует, что эта ситуация маловероятна в условиях штатной работы сервера.

Получив trans_id=0 (сюда можно вписать название любого другого обновляемого параметра), я должен выполнить определённую задачу.
А что потом, когда эта "маловероятная" ситуация произойдёт, я буду просить биржу откатить сделки обратно, потому что Sergey Gorokhov сказал мне, что это "маловероятно"?

Мне не понятны ваши трактовки "частный"/"общий" случай.

Является ли следующая ситуация сбоем на сервере:
когда "сделка приехала раньше ответа на транзакцию" и в этом случае в первом колбеке trans_id=0 даже, если транзакция была подана не через интерфейс?


Я действительно уже многократно задаю один и тот же вопрос. Но я не получаю на него прямого ответа! Перестаньте уже вилять в конце концов.

Как меня может устроить такой вариант, если в вашем предложении нет никакой конкретики?
И потом, почему обязательно Lua? Сервер знает, что транзакция подана через Lua, а не Api или QPILE?

Вы сейчас извиваетесь, как уж на сковородке.
Таким образом, теперь вы сами опровергаете свои же слова о повторной приходе колбека OnTrade необходимостью отправлять дополнительные параметры, в частности uid и trans_id?

Или (задам опять прямой вопрос, на который вы так не хотите давать прямого ответа, хотя вопрос выше был итак достаточно чётким):

Может ли в штатной ситуации trans_id прийти незаполненным (в текущей реализации это означает ноль) в первом колбеке?

На всякий случай, привожу ссылку на ответ более компетентного сотрудника, как это работает в 6-й версии: OnOrder без UID