Михаил Иванов пишет: Приоритеты для меня расставлены по другому
А смысл? Если вы гарантированно (при отсутствии дефолта эмитента) получите доходность именно с учётом дисконта?
Надо делать так, как надо. А как не надо - делать не надо.
message, параметры
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
09.07.2015 14:31:45
Добавьте в параметр "Источник" большее количество источников, например: Сервер биржи; Сервер QUIK; QMonitor; Рабочее место QUIK
Надо делать так, как надо. А как не надо - делать не надо.
Купонная доходность
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
09.07.2015 13:55:29
Есть бескупонные облигации. Доходность по ним определяется по дисконту и/или надбавкой к номинальной стоимости.
Надо делать так, как надо. А как не надо - делать не надо.
Купонная доходность
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
09.07.2015 13:36:22
Цитата
Михаил Иванов пишет: Но при долгосрочном инвестировании в облигации важна чистая Купонная доходность (без учёта цены)
Вообще-то в облигации важна как раз общая доходность с учётом дисконта и купона, а также цены выкупа (погашения/оферты) ;-)
Надо делать так, как надо. А как не надо - делать не надо.
Возможность строить индикаторы по индикаторам
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
08.07.2015 17:57:32
Хотя, можно и побыстрее сделать... Но всё равно, возможность строить индикаторы по индикаторам нужна.
Надо делать так, как надо. А как не надо - делать не надо.
Возможность строить индикаторы по индикаторам
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
08.07.2015 17:31:26
Тут вот какое дело: если строить Lua-индикатор по другому индикатору (неважно встроенному или Lua), с помощью функции getCandlesByIndex, то добавление его на график или полное обновление займёт несколько минут. При большом количестве таких индикаторов запуск QUIK займёт ну ооочень много времени.
Надо делать так, как надо. А как не надо - делать не надо.
Рекламный баннер в ИТС QUIK, Как убрать рекламный баннер в ИТС QUIK
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
08.07.2015 15:26:24
Цитата
Stanislav Tvorogov пишет: Необходимо учесть, что при установленном флаге "Обновлять версию программы" в меню "Настройки/Основные/Программа/" файл будет снова получен при подключении.
Если не ошибаюсь, этот файл будет в любом случае получен при его наличии на текущем сервере, в независимости от настроек.
Надо делать так, как надо. А как не надо - делать не надо.
Разреженный стакан, проблема.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
08.07.2015 13:28:15
Спасибо.
Кстати, неплохо было бы добавить настройку, ограничивающую максимальный размер стакана. А то при "случайном" открытии разряженного стакана по неликвидной бумаге терминал зависает из-за необходимости создавать стакан с огромным числом строк.
Надо делать так, как надо. А как не надо - делать не надо.
Возможность строить индикаторы по индикаторам
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
08.07.2015 12:59:11
Цитата
Дмитрий пишет: Было бы очень хорошо, если бы в качестве источника данных для индикатора можно было выбрать также значения другого, ранее построенного индикатора, то есть строить индикаторы на основе графиков других индикаторов.
Присоединяюсь к пожеланию.
Надо делать так, как надо. А как не надо - делать не надо.
Разреженный стакан, проблема.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
08.07.2015 12:57:51
Сделайте активным пункт настройки "Лучшие спрос и предложение видны всегда" для разряженного стакана. (По-моему такое пожелание регистрировали несколько лет назад). (Кому не надо - тот не будет включать.)
Скрытый текст
Понимаю, что при большом спреде обе котировки одновременно могут быть не видны. В этом случае можно показывать среднюю цену между спросом и предложением (или добавить дополнительную настройку: показывать Bid или Offer). Но обычно при большом спреде разряженный стакан не используют.
Надо делать так, как надо. А как не надо - делать не надо.
Ошибки в функции getQuoteLevel2!!!, Возвращаемый стакан котировок не всегда соответствует (нормальным) условиям...
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
07.07.2015 12:21:43
Цитата
Sergey Gorokhov пишет: Мы провели разбор полученной информации и обнаружили причины описанной Вами проблемы. Временное "увеличение строк в стакане котировок" объясняется итеративностью в обновлении стакана котировок, когда обновляются ценовые уровни, один за другим. В связи с этим, при частом обновлении большого количества ценовых уровней, возникает возможность временно наблюдать окно котировок в состоянии, когда обновлена только часть ценовых уровней, а вторая часть ещё не обновлена и соответствует предыдущему состоянию. В этот момент в стакане могут появляться "лишние строки".
Мы постараемся исправить данную особенность обновления стакана котировок в одной из ближайших версий ПО.
Никаких "особенностей" при "частом обновлении большого количества ценовых уровней" возникать не должно.
Что-то мне подсказывает, что разбор ситуации проведён не тщательно, и действительные причины проблемы не найдены (свои мысли по этому поводу и возможным причинам я направил по e-mail). Одна из причин - изменения строк не в хронологическом порядке, т.е., не в том порядке, в каком они изменялись в действительности. И, как следствие, мы видим большее (меньшее) количество строк в "стакане" и пересечения цен спроса и предложения (, ).
Отсюда у меня есть опасения, что будет устранена не действительная причина проблемы, а произведены, например, "косметические" правки, типа убраны "лишние" строки. Соответственно, есть опасения и за качество данных после таких исправлений.
Поэтому, предлагаю более тщательно исследовать данную проблему.
Надо делать так, как надо. А как не надо - делать не надо.
Количество торгуемых инструментов роботом
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
07.07.2015 11:31:17
Цитата
Sergey Gorokhov пишет: Есть ограничение на чиcло локальных переменных
Цитата
Sergey Gorokhov пишет: Тоже интересно. Беглый поиск в интернете не дал результата.
Да, есть такое ограничение. Не помню точное число. Но вы можете определить это экспериментальным путём, создав большое число локальных переменных ;-) Соответственно, это ограничение можно обойти созданием ещё одной функции и переносом части вычислений и переменных в неё. Или созданием таблицы переменных.
Виталий, для ваших целей QPILE не подойдёт. Да и то, что он "более простой" - спорное утверждение. Начните сразу с изучения Lua. Для воспроизведения звукового файла можно использовать библиотеку
Надо делать так, как надо. А как не надо - делать не надо.
Сделайте на графиках разметку начала и конца торгового дня, нужны вертикальные линии, обозначающие время 10:00, 23:45
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.07.2015 23:31:25
Да, вертикальной линии на 19 часов явно не хватает. :\
Надо делать так, как надо. А как не надо - делать не надо.
Ошибки в функции getQuoteLevel2!!!, Возвращаемый стакан котировок не всегда соответствует (нормальным) условиям...
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.07.2015 10:29:05
Sergey Gorokhov, мне не хочется с вами спорить, но сам ваш вопрос
Цитата
Sergey Gorokhov пишет: Просьба привести пример скрипта считывающего bid_count и offer_count Также сообщите версию терминала и уточните это боевой доступ или тестовый?
говорит о том, что вы либо не в курсе проблемы (в чём я сомневаюсь), либо просто не хотите заниматься проведением анализа и всячески пытаетесь оттянуть этот неприятный для вас момент. Поэтому, перестаньте уже пререкаться и займитесь, наконец, проведением анализа: дополнительной информации вам не требуется. Повторяю: проблема имеет место быть на боевом сервере, на версиях QUIK 6.17.x, 6.16.x и ниже. Код и логи уже давно имеются в вашем распоряжении. Было бы желание...
Надо делать так, как надо. А как не надо - делать не надо.
Ошибки в функции getQuoteLevel2!!!, Возвращаемый стакан котировок не всегда соответствует (нормальным) условиям...
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.07.2015 10:01:32
Sergey Gorokhov, автор вам сообщает, что размеры "стаканов" часто не соответствуют стандартным. Связана ли эта проблема с упомянутой мной или нет - это вы сами разберитесь. Только зачем делать вид, что вы первый раз об этом слышите и задавать глупые вопросы? Проблема имеет место быть на боевом сервере. И вы давно располагаете кодом и логами, чтобы убедиться в этом воочию и разобраться в проблеме, а не напрягать автора зазря. А то сейчас ещё попросите архив рабочего места и видео прислать.
Весёлые картинки:
Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
Ошибки в функции getQuoteLevel2!!!, Возвращаемый стакан котировок не всегда соответствует (нормальным) условиям...
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
03.07.2015 08:53:52
Цитата
Sergey Gorokhov пишет: Просьба привести пример скрипта считывающего bid_count и offer_count
Добрый день.
Не надо делать вид, что вы первый раз об этом слышите! Я отправлял логи со "стаканами" по вашему же скрипту ещё 09.06.2015 в рамках разбора проблем с некорректными данными в очереди котировок (CQ01635062), (CQ01635170). В этих логах, где bid >= offer, размеры стаканов часто не соответствуют стандартным размерам 20х20 или 50х50. Поговорите с Михаилом Шубиным, если не в курсе.
DronGO, вы ещё проверьте, чтобы bid был меньше offer:
Код
function OnQuote(class_code, sec_code)
local tStakan = getQuoteLevel2(class_code, sec_code)
local nOffer_Count, nBid_Count = tonumber(tStakan.offer_count), tonumber(tStakan.bid_count)
if nOffer_Count ~= 0 and nBid_Count ~= 0 then
local nOffer = tonumber(tStakan.offer[1].price)
local nBid = tonumber(tStakan.bid[nBid_Count].price)
if nBid >= nOffer then
_toLog("[OnQuote] "..sec_code..": Bid="..nBid.." >= Offer="..nOffer)
end
end
end
Разработчики утверждают, что у них проблема не воспроизводится на фондовой секции (про валютную пока молчат). Хотя у других проблема имеет место быть как на срочной, так на фондовой и валютной секциях рынка. Просто на фондовой секции пересечения могут возникать не каждый день. Видимо, тестерам не хватает терпения протестировать и зафиксировать проблему...
Надо делать так, как надо. А как не надо - делать не надо.
Отображение типа опциона в "позициях"
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
02.07.2015 10:31:30
Цитата
Вадим пишет: вопрос в том, как быстро понять, какие из них коллы и какие - путы.
Можно использовать условное форматирование в таблице позиций для раскраски колов и путов в разные цвета. Но, если покупаются опционы с разными датами экспирации, то не хватает условий для раскрасок.
Надо делать так, как надо. А как не надо - делать не надо.
OnOrder без UID
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
01.07.2015 13:15:26
Цитата
Egor Zaytsev пишет: Ontrade может быть вызван два раза например, в случаях потери связи между торговой системой и сервером QUIK, а затем получение всей информации заново. В таком случае клиент два раза получит не только заявки, но и сделки.
А, понял. Сразу не сообразил...
Надо делать так, как надо. А как не надо - делать не надо.
OnOrder без UID
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
01.07.2015 12:53:35
Если у вас есть ссылка на обсуждение (и главное ответы) по этому вопросу, то, дайте, пожалуйста, ссылку. (В документации, к сожалению, нет ни информации, ни ссылки на обсуждение)
Надо делать так, как надо. А как не надо - делать не надо.
OnOrder без UID
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
01.07.2015 12:50:27
Цитата
Egor Zaytsev пишет: Ontrade может быть вызван два раза например, в случаях потери связи между торговой системой и сервером QUIK, а затем получение всей информации заново. В таком случае клиент два раза получит не только заявки, но и сделки.
Если пользователь производил очистку данных, то, очевидно, что после подключения к серверу, информация по сделкам придёт повторно. Это понятно, и, наверное, на этом не стоит заострять внимания. В каком случае, клиент повторно получит данные, если очистка данных на клиентке не производилась?
Надо делать так, как надо. А как не надо - делать не надо.
ещё много много раз - потокобезопасные операции, Потокобезопасность.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
30.06.2015 14:58:07
Пример можете привести?
Надо делать так, как надо. А как не надо - делать не надо.
OnOrder без UID
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
30.06.2015 14:32:17
Цитата
Олег Хуснутдинов пишет: даже если OnTrade вызывается более одного раза по одной и той же сделке, такое тоже может быть
Считаете ли вы эту информацию существенной? Почему данный факт не отражён в официальной документации по QLUA, а узнаём мы об этом только сейчас случайным образом?
Цитата
Старатель пишет: В каких ещё ситуациях OnTrade по одной сделке может вызываться более одного раза?
Надо делать так, как надо. А как не надо - делать не надо.
ещё много много раз - потокобезопасные операции, Потокобезопасность.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
30.06.2015 14:27:03
И как поступить, если необходима запись из main и из колбеков в один файл? Вариант ставить флаг, когда производится запись в файл, не возможен, т.к. начиная с версии 6.17 QUIK зависает при вставке ожидающих циклов repeat until и while do в колбеках.
Надо делать так, как надо. А как не надо - делать не надо.
Надо делать так, как надо. А как не надо - делать не надо.
Юридическая сторона вопроса. (ГК РФ Глава 70)
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
25.06.2015 14:07:24
Цитата
Vitaly Skorobogatov пишет: С точки зрения получения доступа к данным Рабочего Места QUIK, а также вызова его внутренних функций и интерфейсов, скрипту на языке LUA разрешается использовать только методы явно описанные в документации на Рабочее Место QUIK. Это замечание распространяется на все вызовы, осуществляемые не только из самого скрипта LUA, но также из загружаемых скриптом библиотек.
В свете вышесказанного как можно расценить совет вашего коллеги, Сергея Горохова, ?
Надо делать так, как надо. А как не надо - делать не надо.
27.04.2015 10:40:02 Ваше обращение по поводу смещения линий при смене сессии получено, проблема изучается. Постараемся в ближайшее время дать ответ.
Думаю, устранение данной проблемы с десятилетней историей должно быть для компании делом чести. Исправить да и закрыть этот вопрос.
Надо делать так, как надо. А как не надо - делать не надо.
Длина таблицы
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
25.06.2015 11:12:55
Получается использование оператора # для таблицы с целочисленными индексами не имеет смысла, если только достоверно не известно, что элементы таблицы заполнены без пропусков. В противном случае результат может быть не предсказуем.
Надо делать так, как надо. А как не надо - делать не надо.
Надо делать так, как надо. А как не надо - делать не надо.
Длина таблицы
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
25.06.2015 10:00:41
s_mike@rambler.ru, Во-первых, документация не моя. Это официальная документация. Во-вторых, вы явно не поняли смысл этого "any":
Цитата
The length of a table t is defined to be any integer index n such that t[n] is not nil and t[n+1] is nil; moreover, if t[1] is nil, n can be zero. For a regular array, with non-nil values from 1 to a given n, its length is exactly that n, the index of its last value. If the array has "holes" (that is, nil values between other non-nil values), then #t can be any of the indices that directly precedes a nil value (that is, it may consider any such nil value as the end of the array).
Надо делать так, как надо. А как не надо - делать не надо.
Согласно , длина такой таблицы (#tab) должна быть 6, но у меня показывает 9. Это ошибка в документации или в самом Lua/QLUA?
Надо делать так, как надо. А как не надо - делать не надо.
luasql (проблема с cursor:fetch)
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
24.06.2015 22:45:06
Надо делать так, как надо. А как не надо - делать не надо.
Расчёт индекса РТС
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
24.06.2015 16:45:51
Не ту ссылку дал. Вот правильная:
Надо делать так, как надо. А как не надо - делать не надо.
Расчёт индекса РТС
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
24.06.2015 16:34:36
Надо делать так, как надо. А как не надо - делать не надо.
Расчёт индекса РТС
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
24.06.2015 16:32:05
Думаю вам понадобится:
Надо делать так, как надо. А как не надо - делать не надо.
luasql (проблема с cursor:fetch)
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
24.06.2015 15:01:53
Код
cursor, err = con:execute(sQuery)
Посмотрите сообщение об ошибке err
Надо делать так, как надо. А как не надо - делать не надо.
Сделайте на графиках разметку начала и конца торгового дня, нужны вертикальные линии, обозначающие время 10:00, 23:45
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.06.2015 21:33:56
По факту: если начало новой свечи с новой датой, - то ставим перед ней метку.
Надо делать так, как надо. А как не надо - делать не надо.
переменная с ошибкой
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.06.2015 17:27:37
Вариант 1:
Код
if tostring(math.abs(a)) == "1.#INF" then print("Неожиданный результат") end
Вариант 2:
Код
infinity = 1/0
if a == infinity or a == -infinity then print("Неожиданный результат") end
Кстати, 1.#IND - значение типа number.
Надо делать так, как надо. А как не надо - делать не надо.
переменная с ошибкой
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.06.2015 17:11:20
Как-то так?
Код
if c ~= 0 then
a = b / c
print(a)
else print("Что я делаю?! Нельзя на ноль делить!") end
Надо делать так, как надо. А как не надо - делать не надо.
Сделайте на графиках разметку начала и конца торгового дня, нужны вертикальные линии, обозначающие время 10:00, 23:45
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.06.2015 13:14:53
С концом торгового дня проблем нет: последняя свеча в сутках - конец торгового дня.
Надо делать так, как надо. А как не надо - делать не надо.
Ограничение на количество отображаемых свечей на графиках
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.06.2015 13:07:08
Цитата
sam063rus пишет: не чаще 1р/с происходит в данном случае получение сделки из твс, а оконные сообщения и возможный запрос на полную перерисовку - отправляется на каждый WM_PAINT
Не путайте ТВС с графиками. Повторяю: У меня цена последней сделки на графике обновляется не чаще 1 раза/сек.
Цитата
sam063rus пишет: происходит - только не отображается - иначе бы при переходе на вкладку - там была бы не актуальная информация в первоначальный момент, и к тому же - есть роботы, индикаторы - они привязаны к графикам -им абсолютно параллельно активна или свёрнута вкладка - им торговать надо.
Мы ведь сейчас говорим о визуальном обновлении графиков, так? Так вот, роботам без разницы, как расположены свечки на том или ином графике. Данные они берут не с самих "картинок".
Надо делать так, как надо. А как не надо - делать не надо.
Что предпочесть при выборе провайдера VDS ?, многоядерность или оперативки побольше
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.06.2015 12:51:58
Цитата
Дмитрий пишет: По-моему терминал всегда использует для работы только 1 ядро, независимо от их количества в процессоре (если не считать работы функций main() в скриптах - про них ничего не могу сказать).
Запустив несколько Lua-скриптов в терминале можно загрузить все доступные ядра процессора на полную. Но, поскольку все портфели QPILE работают в одном потоке (вот только не помню в основном с самим QUIK или для них создаётся дополнительный поток?), то в 4 ядрах нет никакой необходимости. 2 ядра - под вопросом?
Надо делать так, как надо. А как не надо - делать не надо.
Ограничение на количество отображаемых свечей на графиках
sam063rus пишет: положение всех свечек на графике пересчитываются при каждом приходе сделки на график, при масштабировании
Наверное, все-таки не всех, а только тех, которые видны на графике в данный момент. Обычно это меньше, чем 3000.
в этом, наверно соглашусь - бо как не знаю исходную реализацию.
Если это так, то снятие ограничения в 3000 свечей не должно повлиять на производительность, если только не показан весь график целиком.
Надо делать так, как надо. А как не надо - делать не надо.
Ограничение на количество отображаемых свечей на графиках
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.06.2015 12:41:42
Цитата
sam063rus пишет: поверьте, в современных новомодных операционных системах - не одна сотня процессов/сервисов работает в системе - так что, от этого пока ещё никто не ушёл.
Не надо троллить - вы поняли о чём я. Большинство работающих в фоне процессов/сервисов отъедают менее 10Мб ОЗУ и 0% ЦП.
Цитата
sam063rus пишет: и не забываем, что положение всех свечек на графике пересчитываются при каждом приходе сделки на график, при масштабировании.
Ну, да, тут вы правы. Но это ничто по сравнению с полигональными моделями в 3D играх, ведь так? У меня к примеру графики обновляются не чаще 1 раза/сек. К тому же, возможно я ошибаюсь, но полагаю, что на неактивных вкладках или свёрнутых окнах обновления графиков не происходит.
Надо делать так, как надо. А как не надо - делать не надо.
Ограничение на количество отображаемых свечей на графиках
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.06.2015 12:26:00
Цитата
sam063rus пишет: покажите мне современную игру - в которой одновременно 3000 "мобов" на уровне.
Под "мобом" вы подразумеваете самостоятельный объект, обладающий "интелектом" и состоящий из десятков а то и сотен полигонов? Какое это отношение имеет к статическому объекту типа "свеча"?
Надо делать так, как надо. А как не надо - делать не надо.
Ограничение на количество отображаемых свечей на графиках
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.06.2015 11:47:53
Разумному человеку не придёт в голову запускать на компьютере одновременно сотню приложений, если на компьютере всего 1Гб памяти. Есть большая вероятность, что Windows, если не "упадёт", то, как минимум, "зависнет". Так и с QUIK. Вам дают инструмент, а как его использовать - решаете вы сами. Вы можете наоткрывать кучу таблиц/графиков, но если вы переоцените возможности своего компьютера, то результат будет соответствующий.
Надо делать так, как надо. А как не надо - делать не надо.
QLua-Indicators SandBox Internals
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
22.06.2015 19:54:06
Тогда можно предположить следующий алгоритм. Из документации:
Цитата
При выборе пункта меню Настройки/Сохранить настройки в файл, сохраняются все значения из таблицы Settings в wnd-файл. При загрузке настроек из файла, модуль qchart получает от модуля qlua список индикаторов и автоматически создает индикатор по его имени.
При этом имя самого файла Lua-индикатора не сохраняется. Поэтому при создании индикатора последовательно перебираются файлы из папки LuaIndicators, пока не будет найден индикатор с именем Settings.Name. Поиск, очевидно, происходит путём их запуска.
Надо делать так, как надо. А как не надо - делать не надо.
OnOrder без UID
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
22.06.2015 18:58:15
Цитата
Олег Хуснутдинов пишет: теоретически, обновлён (дописан/удалён) может быть любой параметр, кроме ключевых (ключевые это Номер заявки, Дата торгов, Код класса).
Т.е., возможна такая ситуация, когда OnOrder может прийти, скажем, с незаполненным параметром account, balance или sec_code? И какое в этом случае будет значение параметра: nil или ""/0 в зависимости от типа? И в этом случае не стоит бить тревогу? Или стоит?
Цитата
Олег Хуснутдинов пишет: даже если OnTrade вызывается более одного раза по одной и той же сделке, такое тоже может быть и не является аномалией
То, что OnTrade может вызываться более одного раза - я в курсе: при переключении на другой сервер или очистке данных (файл trades.dat, как я понимаю). В каких ещё ситуациях OnTrade по одной сделке может вызываться более одного раза?
Надо делать так, как надо. А как не надо - делать не надо.