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

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

Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 77 След.
Ошибка в данных источника DataSource (брокер ВТБ)
 
Цитата
Blackninja написал:
На график эти данные не выводил.
Постройте график и посмотрите.
Очевидно же, если на графике такая же ситуация значит проблема на стороне брокера, если нет значит на стороне скрипта
Как насчет пинга?
 
Цитата
shkidec написал:
Цитата
Stanislav Tvorogov написал:
Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что мы также считаем целесообразным его реализацию и постараемся включить в план доработок при выпуске одной из следующих версий нашего ПО.
Доброго здоровья, Станислав!!!
Подскажите, предложения реализованы? С какой версии рабочего места? В каком файле находятся настройки соединений?
У меня версия 7.25. В ней уже реализовано слежение за соединениями с серверами?
Здравствуйте.
нет.
Кривые шибки в QLua
 
Добрый день,

Мы рекомендуем отказываться от использования Lua 5.3 и переходить на Lua 5.4. Какие-либо доработки в Lua 5.3 не планируются.
Не выводит параменты "OPTION_TYPE", "OPTIONBASE" и некоторые другие, выводит ошибку(= 0) при запросе некоторых параметров
 
Это строковые параметры, а не числовые. Значит выводить надо param_image
Ошибка в данных источника DataSource (брокер ВТБ)
 
А если открыть график и посмотреть, там так же?
WebQuik API
 
Цитата
Яна написал:
Коллеги, изменилось ли что-то с момента последнего ответа? Очень нужен нормальный API  к квику.
Выпуск такого API не планируется, потому что уже есть FIX приборы.


Цитата
Яна написал:
Кстати, у ИБ даже курс по программированию на их API выложен, поэтому нам бы тоже такое не помешало. Безусловно за такой курс готов заплатить.
таких планов у нас также нет.
Версия 9.* isDarkTheme в индикаторах
 
Проблема изучается. Постараемся в ближайшее время дать ответ.
Версия 9.* isDarkTheme в индикаторах
 
Здравствуйте,
Проблема не воспроизводится.


Проверьте еще раз Ваш код
Что делает SetEmptyCallback() ?
 
Цитата
BlaZed написал:
SetEmptyCallback это атавизм или все же есть ситуации когда он еще актуален?

Да он не нужен
Индикатор RSI из INDICATORS.ZIP вылетает с ошибкой
 
Цитата
Let_it_go написал:
Вызывается следующим блоком:
Нужен полный код на котором воспроизводится
Прошу помочь исправить ошибку в коде, Скрипт при запуске в QUIK выдаёт ошибку: "18: attempt to index a nil value (global 'ds')"
 
Цитата
Алексей написал:
Class_Code = "QJSIM"         -- класс торгуемого инструмента

точно ли код класса указан верно?
Такой класс есть только на нашем демо контуре, у брокеров нужно указать TQBR
При снятии заявки перемерт account пустой
 
Для заявок OrderNum+ClassCode+TradeDate
Для сделок TradeNum+Operation+ClassCode+TradeDate
Для обезличенных сделок TradeNum+ClassCode+TradeDate+SecCode

на сделках (не обезличенных) нумерация на разных инструментах одного класса не совпадает.
Да это значит что номер одной сделки в обезличенных, и в обычных, может быть разным
При снятии заявки перемерт account пустой
 
Старатель,
Уже был развернутый ответ
При снятии заявки перемерт account пустой
 
Старатель,
Речь о некоторых зарубежных шлюзах, где номер обезличенной сделки может быть один на разных инструментах одного класса.
В свое время, из-за этого SecCode был добавлен в список первичного ключа таблицы AllTrades в модуле экспорта биржевой информации.
При снятии заявки перемерт account пустой
 
Старатель,
К сожалению в ответе произошла ошибка.
Заявки не могут быть с совпадающим номером на одном классе.
И SECCODE на транзакции KILL_ORDER не нужен.
И в Lua тоже. Почему у автора не получилось снять заявку не понятно.
На самом деле номер в разрезе инструмента может совпадать только на обезличенных сделках
Написание автономного бота
 
Mixa,
Вам уже было сказано что согласование с разработчиком возможно исключительно только после регистрации пожелания.
Пожелание зарегистрировано, информация ушла разработчикам, ждите ответ.
Отладка QUIK 9.1
 
Цитата
BlaZed написал:
QUIK создает во всех папках где есть *.lua файлы файл qrypto.log с таким содержанием
Проблема изучается. Постараемся в ближайшее время дать ответ.
Написание автономного бота
 
Цитата
Mixa написал:
Но это же не прямой запрос на сервер. getServerNumberOf вернет последнее значение, полученное с сервера. Или я вас не так понял?
Речь была именно про запрос на сервер. те запрос к серверу, сколько есть на сервере в такой-то таблице.
Написание автономного бота
 
Цитата
Mixa написал:
Пока не будет получено новое значение "доступных лимитов на сервере" с нового шлюза, условие getServerNumberOf("depo_limits") == getNumberOf("depo_limits")будет выполняться.

Вы боитесь что сервер подсчитает сколько лимитов отправить пользователю с задержкой, т.е. пользователь получил класс и право им торговать, но сам сервер еще не одумался есть ли у пользователя лимиты? Такая ситуация невозможна, если бы она существовала то это была бы дырень в безопасности.
Написание автономного бота
 
Цитата
Mixa написал:
Для этого надо гарантировать, что сервер отправит количество доступных на сервере лимитов ДО описания параметров таблицы Торговые счета.
Мы же договорились что getServerNumberOf вернет данные в момент запроса. Хотите запрашивайте ДО описания параметров таблицы Торговые счета, хотите после. Вам уже решать

Цитата
Mixa написал:
В противном случае, getServerNumberOf("depo_limits") = N и getNumberOf("depo_limits") = N

Не доказано.
Вам уже было сказано что лимиты НЕ привязаны к классам, это можно читать так что лимиты НЕ привязаны к шлюзам (исключение только срочный рынок)

Если второй шлюз подключился, и засылает те же бумаги что и первый, с теми же фирмой и счетом, значит у пользователя УЖЕ есть нужные лимиты (получил при первом шлюзе) и условие сработает т.к. грузить просто ничего не надо.

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

Если счет и фирма та же, но бумаги другие, значит либо будет лимит по новым бумагам (условие не сработает), либо лимитов вообще нет и не будет (это допустимо т.к. ранее уже был лимит с нужным счетом).
Написание автономного бота
 
Цитата
Mixa написал:
Но и getServerNumberOf("depo_limits") == getNumberOf("depo_limits") = N  -- выполняется Хотя лимиты со второго шлюза могут быть еще не загружены!

ответ УЖЕ был:
Цитата
Sergey Gorokhov написал:
Если лимит есть на сервере, но еще не загружен в терминал то условие НЕ выполнится и getNumberOf("depo_limits") покажет МЕНЬШЕ чем getServerNumberOf("depo_limits").
Написание автономного бота
 
Цитата
Mixa написал:
то оба эти условия выполнятся раньше, чем загрузится лимит.
Ошибаетесь.
Если лимит есть на сервере, но еще не загружен в терминал то условие НЕ выполнится и getNumberOf("depo_limits") покажет МЕНЬШЕ чем getServerNumberOf("depo_limits").


Цитата
Mixa написал:
И это заблуждение.
Ошибаетесь.
Раз данные получены с сервера, значит либо лимит есть и тогда Вы его увидите в depo_limits.
Либо лимита нет, просто нет, а не "еще не загружен".
Написание автономного бота
 
Mixa,
Пожелание уже было зарегистрировано (см соседнюю ветку).

Цитата
Mixa написал:
У вас выполнится условие getServerNumberOf("depo_limits") == getNumberOf("depo_limits"), когда загрузятся лимиты по любому рынку. А запись в trade_accounts может точно появится раньше, чем загрузятся лимиты по бумаге X.
И что это меняет? Пожелание было зарегистрировано с оговоркой чтобы гипотетическая функция getServerNumberOf будет работала для всех таблиц из списка getItem, в том числе и trade_accounts.
Таким образом, Вы сможете проверить наличие прав при условии что getServerNumberOf("trade_accounts") == getNumberOf("trade_accounts")
т.е. после того как (getServerNumberOf("depo_limits") == getNumberOf("depo_limits")) и (getServerNumberOf("trade_accounts") == getNumberOf("trade_accounts")), проверяем по trade_accounts наличие прав на нужный класс и ищем в depo_limits нужный лимит, уже уверенные что данные получены с сервера.
Получение позиций по инструментам
 
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Написание автономного бота
 
Цитата
Mixa написал:
С учетом того, что сервер должен отправить "количество строк доступных на сервере" ДО описания параметров таблицы Торговые счета.

Ранее было сказано что у нас нет структуры определяющей строгость загрузки тех или иных данных.
Проще говоря, никто не следит за тем какие данные придут точно раньше, а какие точно позже.
Очередности просто нет. А значит и поменять ее нельзя.
Причина в том что данные едут разными потоками, которые между собой никак специально не синхронизируются.
Да есть некое условное представление о том что приедет раньше, а что позже, но это не вбито в коде, а просто устоявшееся поведение, которое может поменяться в любой момент.
№ номер заявки 1.952337642788e+018 VS 2 952 137 242 587 989 181
 
Цитата
Иван написал:
Правильно ли понимаю если у меня по какой-то причине будет в течении дня сгенерировано два одинаковых TRANS_ID с одинаковыми номерами - максимум чем мне это грозит при снятии стоп-лоса, это то, что будет снят только 1, а второй останется болтаться?
Для того чтобы снять стоп, параметр TRANS_ID вообще не нужен.
В транзакции на снятие стопа есть только номер стоп заявки, это НЕ тоже что TRANS_ID.

TRANS_ID - Нужен исключительно Вам т.е. Вашему роботу. QUIK на него вообще никак не смотрит.
Нам не известно какая логика заложена в Вашем роботе, следовательно не можем ответить на вопрос о его поведении.
Написание автономного бота
 
Цитата
Mixa написал:
Напишите псевдокод, как это использовать.

Код
function main()

  while getServerNumberOf("depo_limits") != getNumberOf("depo_limits") do
    sleep(100)
  end

end
№ номер заявки 1.952337642788e+018 VS 2 952 137 242 587 989 181
 
Цитата
Иван написал:
Мне нужно как-то сгенерировать TRANS_ID - уникальное число со смыслом. А не просто уникальное число.
Не понятно что Вам мешает это сделать
Есть понимание какой смысл в TRANS_ID Вам нужен? Если нет, тогда определитесь и далее исходя из этого действуйте.
№ номер заявки 1.952337642788e+018 VS 2 952 137 242 587 989 181
 
Цитата
Иван написал:
А UNIX TIME как получить?
UNIX TIME - это просто количество секунд начиная с какой-то даты (1 января 1970г).
можно получить через тот же os.date
Судя по всему, Вам не это нужно.
Просто сами определите для себя какое число Вам требуется и сгенерируйте. тех поддержка в этом месте не причем.
Вопрос только и только на Вашей стороне.
Хотите, считайте тот же UNIX TIME но с 2000 года
или "сожмите" дату до нужного размера (например сложив чила)
Или другие варианты которые Вам понравятся.
Написание автономного бота
 
Цитата
Mixa написал:
ДО или ПОСЛЕ загрузки лимитов? Это ключевой момент.

Определите самостоятельно, это не так трудно.

Цитата
Mixa написал:
Это будет то же гадание, что и сейчас: загрузились/не загрузились.
Еще раз. Если количество строк в таблице терминала равно количеству строк на сервере, это УЖЕ факт того что данные загрузились.
Какие данные? Вы УЖЕ можете проверить т.к. есть факт что они загрузились.

Цитата
Mixa написал:
Sergey Gorokhov , вы вообще понимаете разницу между состояниями 1) "загрузка еще не началась", 2) "идет процесс загрузки данных" и 3) "загрузка закончена"?Пока вы не поймете эти базовые вещи, у вас так и будут "вопросы и примеры трудности реализации".
А Вы понимаете, что Вам уже несколько раз было предложено?
Цитата
Mixa написал:
Если уведомление получено, а данных нет, значит их действительно нет. Это не то же самое, что сейчас, когда вы не можете определенно сказать  "нулевая ли позиция" или "она ещё не получена с сервера" .
И в чем разница:
"если количество строк в таблице = количеству на сервере, значит данные загружены, а раз нужных данных в таблице нет, значит их действительно нет.

??
Докажите что Ваше предложение хоть чем-то отличается от нашего?
разница только в том что наше в разы проще в реализации.

Цитата
Mixa написал:
Как интерпретировать такую информацию: запись {Firm2 = {D, E}} в trade_accounts есть, а самого лимита по бумаге X в таблице лимитов нет?
Выше было сказано, цитата:
Цитата
Sergey Gorokhov написал:
Пока лимиты грузятся можно было бы добавить проверку "Флаг загрузки данных".
Ситуация:
Запись {Firm2 = {D, E}} в trade_accounts есть, значит права есть. И это точно.
флаг, что все данные в таблице загружены получили.
Нужного лимита среди данных нет, значит его просто нет (брокер не загрузил)

Цитата
Mixa написал:
Конкретизирую вопрос: следует ли из вашего утверждения, что сначала будут ПОЛНОСТЬЮ загружены лимиты по классам D и E для Firm2 и лишь затем в trade_accounts появится запись с {Firm2 = {D, E}}?
Это легко проверить самостоятельно
Цитата
Mixa написал:
Добавьте эту информацию в официальную документацию по QLua.

У нас нигде нет никакой структуры определяющей строгость загрузки тех или иных данных.
№ номер заявки 1.952337642788e+018 VS 2 952 137 242 587 989 181
 
Иван,
Дополним,
судя по всему вопрос не технический, а логический. Нам не важно что вы напишите в TRANS_ID, главное чтобы размер был не больше «2 147 483 647»

Вы сами решите для себя нужна ли Вам вообще os.date("%d%H%M%S"), может ее не надо там указывать и все?
если нужна, сами для себя решите зачем, может там достаточно краткого формата ДДММГГ

Если вопрос в том, как в os.date указать выходной формат, то ответ есть в документации на Lua
№ номер заявки 1.952337642788e+018 VS 2 952 137 242 587 989 181
 
Иван,
Вы же сами сказали что от «1» до «2 147 483 647»
В чем сложность сгенерировать число входящее в этот диапозон не понятно.
Если хочется получить его из даты, тот же UNIX TIME вполне в него влезает
Соответствие Кодов клиента и Торговых счетов, Определение соответствия Кодов клиента и Торговых счетов
 
Цитата
Незнайка написал:
Но в форме ввода заявки нет идентификатора фирмы. Как же квик определяет, по какой фирме совершать сделку?

Если фирмы нет, значит в правах на классе только одна фирма.
Возможность торговли от разных фирм доступна только сотрудникам брокера.
Написание автономного бота
 
Mixa,
По сути Вы хотите две разные вещи. Флаг загрузки данных (его нет) и флаг наличия прав (уже есть в trade_accounts).
Вы же всеми силами пытаясь объединить два разных флага в одну функцию по косвенным признакам. А это вызывает вопросы и примеры трудности реализации.
Проще говоря, возникает слишком много разных "если".
Предложенный пример не будет надёжно работать т.к. наличие прав не всегда равно наличию данных.

Ранее Вы сами предложили
Цитата
Mixa написал:
Посчитать количество записей в таблице на сервере и отправить число клиенту. В чем проблема?
Вам предлагалось зарегистрировать такое пожелание. А именно проверку количества строк в таблице с количеством строк доступных на сервере.
Если количество совпадает то данные загружены, если нет грузятся.
И на наш взгляд такая реализация вкупе с проверкой trade_accounts решает поставленную Вами задачу, без излишних "если".

Цитата
Mixa написал:
Пример:

У пользователя есть права на классы A, B по фирме Firm1 и классы D, E по фирме Firm2.
Бумага X торгуется в классах A, C и E
Скрипт торгует бумагой X в классе E, соответственно ждет лимит по фирме Firm2: isLimitsLoaded(Firm2, E)
Сервер подключен к двум шлюзам: первый шлюз транслирует классы A, B, C по фирме Firm1; второй - классы D, E по фирме Firm2.

После подключения первого шлюза сервер сверяет транслируемые классы с правами пользователя и формирует табличку вида {Firm1 = {A, B}}
Пользователю приходят лимиты по бумагам, содержащимся в классах A и B, в т.ч. по бумаге X. Как обычно,  в этой части никаких изменений не требуется!
И после загрузки всех лимитов (даже если их там было 0) сервер отправляет уведомление клиенту {Firm1 = {A, B}}.
Но isLimitsLoaded(Firm2, E) = false, поэтому скрипт ждет.

Далее запускается второй шлюз.
И клиенту транслируются лимиты по бумагам D и E. Поскольку лимиты по бумаге X уже были раннее загружены, то повторно не транслируются. Все как обычно,  в этой части никаких изменений не требуется!
Затем клиенту отправляется уведомление {Firm2 = {D, E}}. Это уведомление формируется на основании прав, не лимитов!
После его получения isLimitsLoaded(Firm2, E) = true  =>  Лимиты по  бумаге X  загружены, можно торговать в  классе E .

В данном конкретном примере функция isLimitsLoaded вообще не нужна, и даже "Флаг загрузки данных" не обязателен, хотя его можно было бы добавить при желании:

После подключения первого шлюза сервер сверяет транслируемые классы с правами пользователя и отправляет клиенту trade_accounts в которой уже есть данные вида {Firm1 = {A, B}}
Пользователю приходят лимиты по бумагам, содержащимся в классах A и B, в т.ч. по бумаге X. Как обычно,  в этой части никаких изменений не требуется!
Пока лимиты грузятся можно было бы добавить проверку "Флаг загрузки данных".
Но в trade_accounts нет {Firm2 = {D, E}}, поэтому скрипт ждет.

Далее запускается второй шлюз.
И клиенту транслируются лимиты по бумагам D и E. Поскольку лимиты по бумаге X уже были раннее загружены, то повторно не транслируются. Все как обычно,  в этой части никаких изменений не требуется!
Клиент уже может проверить наличие {Firm2 = {D, E}} в trade_accounts
Если есть  =>  Лимиты по бумаге X  загружены (скрипт может это проверить в таблице лимитов), можно торговать в  классе E.
Получение признака "Субординированный инструмент" в lua
 
Цитата
swerg написал:
Цитата
Roman Azarov написал:
В текущей реализации, экспорт таблицы текущих торгов возможен только средствами DDE (не обязательно в Excel) и ODBC.
Можем зарегистрировать пожелание на возможность экспорта в текстовый файл. Регистрируем?
Зарегистрируйте другое пожелание.
Из ТТТ должен открываться таблица, отображающая соответствие названий параметров и их "формальное название".
Тогда каждый сам легко и наглядно сможет это соответствие увидеть без всяких DDE и экселов.
С обязательной возможностью копирования данных из такой таблицы!!! чтобы не приходилось перепечатывать названия параметров.

Вам в этом случае не придется поддерживать актуальность документации, просто отпадает надобность в документировании.

Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Получение признака "Субординированный инструмент" в lua
 
_sk_,
Если права одинаковые, тогда да.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
Действительно ли могут прийти колбеки заявок других клиентов?
Конечно нет, это исключено. Только брокер может видеть заявки других клиентов.
Написание автономного бота
 
Цитата
Mixa написал:
И после всех объяснений, вы бьете себя пяткой в грудь и кричите: "задача не решаема, закрываем!"
Задача не решаема в том контексте который Вы просите. Ранее Вам предлагался признак загрузки всех строк в таблице лимитов - такое пожелание возможно.
Цитата
Mixa написал:
Тогда при чем здесь "десятки миллионов лимитов"?
Как уже было сказано, в предложенном варианте, серверу понадобится проверить ранее отправленные лимиты, сверив их с поступившим набором инструментов. Чтобы убедиться что отправка действительно была. Иначе вариант с правами не надежен.

Цитата
Mixa написал:
Допустим, получил сервер со шлюза классы "class1,class2,class3" для firmid. Их же он и проверяет в правах (не в лимитах!) пользователей.

Да, сервер проверяет права на классе. Фирма счет (код клиента) и отправляет клиенту те лимиты которые им удовлетворяют.
Что это даст не понятно.
Например на СПБ американские бумаги, на ФР российские, права одинаковые, лимиты разные. В результате только проверки прав недостаточно.

Цитата
Mixa написал:
И это можно использовать для оптимизации: если для пользователя в правах нет ни одного доступного "firmid + class_code" с этого шлюза, то в лимиты можно уже не смотреть.
Cервер так и делает, было же сказано что если прав нет то и лимитов нет.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
Какой правильный формат CLIENT_CODE , если 123456/345 не работает? 345 - это доп данные  
В зависимости от настроек на стороне брокера, код клиента и комментарий могут разделяться либо "/" либо "//".
Посмотрите как оно выглядит у Вас в таблице заявок
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
Он всегда есть в OnOrder, ореде с т.з. елиента. Вы хотите сказать, что вы не можете своими внутренними признаками определить, ручной ордер или нет? Чтобы для ручных возвращать trans_id не так же, как для незаполненных. Ну исторически уже привыкли к 0 для ручных, а для незаполненных тогда просто не возвращать поле (=nil). Из ваших слов про биржу не следует, что вы не можете так формировать свои поля в OnOrder.

Эти "внутренние признаки" есть только на транзакции.
Сервер получает транзакцию и запоминает  "внутренние признаки"
Далее транзакция отправляется на биржу и там регистрируется заявка.
Обратно на сервер отправляется две сущности, ответ на транзакцию (текст типа "ваша заявка зарегистрирована...") и тело заявки (то что в таблице ORDERS биржевого интерфейса).
Далее серверу нужно найти исходную транзакцию и связать ее с заявкой, происходит это через ответ на транзакцию.
В ответе на транзакцию есть номер заявки, в теле заявки тоже есть номер заявки. Таким образом, зная это, сервер может найти исходную транзакцию и взять из нее "внутренние признаки" которые потом установить на теле заявки.
Все усложняет то что тело заявки и ответ на транзакцию едут разными потоками, которые никак между собой не синхронизируются.
Если ответ на транзакцию приехал раньше тела заявки то проблем нет, сервер заранее определяет "внутренние признаки" и когда заявка приедет, отправит ее клиенту вместе с признаками.
Но т.к. потоки не синхронизируются бывают случаи когда тело заявки приезжает ДО ответа на транзакцию. Т.е. сервер получает тело заявки и не может найти исходную транзакцию, тогда тело заявки сразу передается клиенту, а потом, когда поступает ответ на транзакцию, сервер делает еще одну отправку тела заявки, но с уже проставленными "внутренними признаками"
Исходя из этого, отвечаем на вопрос, мы не можем своими внутренними признаками определить, ручной ордер или нет до тех пор, пока не получен ответ на транзакцию.

Цитата
Андрей написал:
И насчет CLIENT_CODE в транзакции. Я его заполняю своим номером. Как его получить в OnOrder? Там нет такого поля, есть похожее по описанию brokerref, но оно не содержит моих данных, а именно /код клиента.

Да brokerref, там должен быть комментарий. Проверьте еще раз.
Написание автономного бота
 
Цитата
Mixa написал:
Я вам пишу, что сами лимиты грузить повторно не надо.
Никто не говорил про повторную загрузку.
Говорилось про проверку доступности, а не загрузку. Это не одно и то же.

Цитата
Mixa написал:
Надо только сверить права на firmid + class_code с теми, что дает шлюз. Если они есть, значит отправляем клиенту уведомление.
По сути это и есть "повторная проверка доступности", разве нет?
И как уже было сказано, trade_accounts это как раз и есть проверка прав по firmid + class_code и Вы сами сказали что задачу это не решает.

Цитата
Mixa написал:
Давайте я буду общаться с программистом на уровне кода, раз вы не понимаете.
К сожалению, наш внутренний регламент не разрешает связь клиента с разработчиком.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
А свои дополнения можно сделать как пишу выше, чтобы не было неразберихи. Либо =nil (отсутствуют в пришедшем ордере), либо -1, пока вы не вставите истинное значение.  
Еще раз, trans_id это наш параметр, его в принципе никогда нет в ордере. Наш сервер его проставляет, а не биржа.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
Приведите пожалуйста полный список полей транзакции, которые входят и в ордера и в биржевой протокол и, значит, заполнены в каждом пришедшем OnOrder.
Это описано в биржевом протоколе, который не является тайной.
описание на сайте биржи:
http://ftp.moex.com/pub/ClientsAPI/ASTS/Bridge_Interfaces/Equities/Equities3­8_Broker_Russian.htm
Написание автономного бота
 
Цитата
Mixa написал:
А нужно уведомление, что получены все лимиты (для данных firmid + class_code).
К сожалению разговор уже идет по кругу.
Никак нельзя определить что лимиты загружены по firmid + class_code.
Просто нет и все.
Дорабатывать как то сервер ради этого нецелесообразно, значит работать только с тем что есть.
А того что есть недостаточно, альтернативный вариант Вас не устраивает.
Итого задача не решаема а значит считается закрытой.
Ок?
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
А вы уверены, что он будет проставлен в этом первом пришедшем OnOrder, в котором даже trans_id  не проставлен? Не думаю.. т.к. транзакция еще не обработана.

CLIENT_CODE - это биржевой параметр. Вы отправляете транзакцию на биржу и в OnOrder приезжает тело заявки с биржи, включая CLIENT_CODE.


Цитата
Андрей написал:
И в любом случае это bad design, о чем я выше пишу, когда не заполненное поле имеет значение, валидное для заполненного. И исправить это не сложно без потерь производительности, нужно сделать.

Мы не можем что-то добавить в биржевой протокол, только биржа это может.
Добавить свои собственные параметры, да можем, и UID и trans_id мы как раз и добавили.
Добавить к ним еще один? Зачем он ведь будет работать точно так же. И с ним будут точно такие же проблемы.
Написание автономного бота
 
Цитата
Mixa написал:
Sergey Gorokhov , вы куда-то ушли от темы.

От чего же, Вы хотели
Цитата
Mixa написал:
лимиты "firmid + class_code загружены". Даже если в этой связке было загружено ноль лимитов.
таблица trade_accounts ровно это и покажет.
Да она не показывает именно лимиты, но Вы сами же сказали что это и не требуется
Ок, смотрите trade_accounts
Если там нет нужной "firmid + class_code" значит и лимитов по ним нет. И это точно.
Если есть, значит лимиты есть, потому что запись там не появится пока не будет получен лимит по любой бумаге связывающей фирму+счет+код клиента.
Написание автономного бота
 
Цитата
Sergey Gorokhov написал:
Цитата
Mixa написал:
Я не говорю про конкретные инструменты. Сервер отправит уведомление, что лимиты "firmid + class_code загружены". Даже если в этой связке было загружено ноль лимитов.
Тогда смысл в чем? Смотрите колбек OnFirm или таблицу firms, там правда нет класса, есть торговая площадка (по сути рынок). Вот Вам и isLimitsLoaded

Нет, лучше trade_accounts (Торговые счета), там есть связка фирма+счет+список классов
Написание автономного бота
 
Цитата
Mixa написал:
Я не говорю про конкретные инструменты. Сервер отправит уведомление, что лимиты "firmid + class_code загружены". Даже если в этой связке было загружено ноль лимитов.

Тогда смысл в чем? Смотрите колбек OnFirm или таблицу firms, там правда нет класса, есть торговая площадка (по сути рынок). Вот Вам и isLimitsLoaded
Написание автономного бота
 
Цитата
Mixa написал:
Серверу достаточно сверить для каких фирм какие классы транслирует шлюз и отправить клиенту true для каждой такой связки firmid - class_code.
Еще раз.
Лимиты не привязаны к классам.
Есть лимит, в нем фирма и инструмент, класса нет.
Как по Вашему, сервер должен понять по  firmid + class_code что например лимит по LKOH из TQBR должен вернуть true, при условии что лимит уже был отправлен в EQRP_INFO?
Допустим, для первого класса EQRP_INFO все понятно, сервер может его запомнить при первой отправке и функция сработает.
Но как он должен понять что по TQBR тоже должен вернуть true? только если залезет в "отправленные" и еще раз проверит лимит по LKOH на доступность.
"Доступность" это ведь не только фирма и класс, но и инструмент же. Если какой то инструмент снимут с торгов (со всех классов), сервер не отправит лимит.
Получается серверу придется выполнить одну работу уже два раза. А у брокера миллионы, десятки миллионов, лимитов по 236 классам и это только ФР. Представьте как север будет их все проверять.
Написание автономного бота
 
Цитата
Sergey Gorokhov написал:
Цитата
Mixa написал:
isLimitsLoaded(firmid, "TQBR") == true сработает именно после запуска шлюза с классом TQBR.
Не сработает, потому что лимиты  уже  были отправлены при появлении EQRP_INFO

Сейчас сервер не проверяет те лимиты которые уже были отправлены.
Если делать по Вашему, то серверу придется при появлении каждого инструмента по каждому классу проверять все ранее отправленные лимиты. Такая нагрузка потенциально увеличит время готовности сервера в разы.
Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 77 След.
Наверх