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

А таблицу транзакций покажите.

Сотрудники брокера ответили вам на от...сь не верно.
Это ответ от шлюза торговой системы. Может означать, что сервер QUIK не может снять одну из заявок 18775681008 или 18775712386.
Сервер посылает транзакцию на снятие либо повторно уже снятой заявки 18775681008 либо уже исполненной 18775712386?
Тут надо смотреть логи сервера.

Снята (мкс) и UID снявшего заявку - ?

Время снятия заявки 18775681008 покажите.

Добрый день.
Продлите, пожалуйста, доступ для UID 93716

Ваша правда: дубликаты OnOrder по-прежнему присутствуют. Вопрос снимается.

Тогда что изменилось?

В QUIK 7.0.3.7 в ответ на транзакцию стал приходить один OnOrder, в отличие от предыдущих версий, где их (OnOrder) было всегда несколько на одну транзакцию.
Означает ли это, что в 7-й версии механизм работы с таблицей заявок изменён, и все параметры заявок всегда заполняются до отправки пользователю?

Делайте как удобно.

Информационно-торговой системы QUIK (в простонародье - терминал QUIK).

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

Данную проблему поднимал почти год назад: Архив графиков.
Проблема в том, что на сервере 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() бумагу уже не из списка не удаляет.