sam063rus пишет: с другой стороны, тут можно не согласиться - бо как за основу взято именно серверное время
Данные для ТВС и для ТТП с одним и тем же серверным временем могут фактически прийти в терминал в разное время (думаю, рассогласование в секунду, а то и больше, тут не будет редкостью). Можно пытаться сопоставлять эти данные уже потом, анализируя историю из ТВС и Таблицы изменений параметров, но все равно синхронизировать их будет весьма проблематично, т.к. время записей в Таблице изменений параметров приводится лишь с точностью до целой секунды. С учетом этого, стоило бы наверное выразить пожелание, чтобы разработчики добавили ко времени записей в Таблице изменений параметров еще и милли- или даже микросекунды.
Брать информацию либо из ТТП в OnParam, либо из ТВС в OnAllTrade И не пытаться сопоставлять данные из этих двух источников, тем более на лету. А если и сопоставлять, то сравнивать их с учетом какой-то заранее заданной допустимой погрешности.
Это нормально, т.к. в скрипте берутся данные из ТТП, а они представляют всего лишь временные срезы информации о числе сделок и прочих параметрах, которые формируются через определенные промежутки времени. А сделки в ТВС поступают в отдельном потоке, никак не синхронизированном с потоком данных ТТП.
Что значит портится? Число сделок уменьшается? Или еще какие-то несоответствия, которые можно описать формально? Тогда выведя в эксель таблицу, которую вы поместили тут в виде картинки, легко можно найти с помощью простой формулы среди множества строк именно те, где видна такая ситуация.
Скорей всего изредка приходят опоздавшие обновления ТТП, в которых время или количество сделок отстали от текущих значений. Попробуйте сделать проверку - если число сделок стало меньше, чем было в предыдущий раз, и время меньше предыдущего или равно ему - то просто не учитывайте пришедшие значения.
Michael Bulychev пишет: Она не следит, а получает с сервера уже готовые посчитанные интервалы
Значит, если нужно получить только свечки графика, сформированные до вызова CreateDataSource, а сформировавшиеся или изменившиеся после этого свечи нас не интересуют, то ни SetUpdateCallback, ни SetEmptyCallback() использовать нет надобности?
sam063rus пишет: то после докачки старых данных... Вы предлагаете мониторить на боевом потоке отстали ли данные или нет?
Чтобы исключить докачку старых сделок (совершенных до момента заказа всех сделок по данному инструменту), можно включить галочку "Получать информацию по всем сделкам с текущего момента" в окне "Связь / Заказ всех сделок".
Тогда, я думаю, неправильной хронологии записей в таблице всех сделок в пределах одной секции рынка возникнуть не должно.
"Округление" до миллисекунд идет только на рынке FORTS. Почему так происходит - наверное, стоит спросить биржу. С фондовой и валютной секций рынка время сделок транслируются с точностью до микросекунд.
Sergey Gorokhov пишет: Указанная проблема у нас не воспроизводится. Тестировали на терминале версии 6.17.1.17. Если у Вас терминал более старой версии, выполните обновление. Если такой же версии, приведите пример скрипта.
Я тестировал на терминале точно такой же версии (на часовом графике, отключив связь с сервером). Вот пример скрипта:
Код
Settings =
{
Name = "Test",
line =
{
{
Name = "Hour",
Color = RGB(0, 255, 0),
Type = TYPE_HISTOGRAM
}
}
}
function Init()
return 1
end
function OnCalculate(index)
if index == 9 then
for i = 1, 8 do
SetValue(i, 1, i) -- 2) получаем значения индикатора: 1, 2, 3, 4, 5, 6, 7, 8, 18
end
end
SetRangeValue(1, 2, 4, -3) -- 3) получаем значения индикатора: 1, -3, -3, -3, 5, 6, 7, 8, 18
return T(index).hour -- 1) получаем значения индикатора: 10, 11, 12, 13, 14, 15, 16, 17, 18
end
В итоге в (отдельном) окне с индикатором отображается шкала по вертикали от 9 до 24 и все первые 8 значений индикатора не видны.
Старатель пишет: Если все сделки заказаны до начала торговой сесссии, то в рамках класса (точнее, торговой площадки) сделки поступают в хронологическом порядке.
sam063rus пишет: Изначально планировалось по рынку - но это оказалось далеко не тривиальной задачей. поэтому ограничился пока одним активом.
Может быть, по определенному классу сделать не сложней, чем по одному инструменту? Насколько я понял из недавних обсуждений на этом форуме, в пределах одного класса сделки в ТВС должны идти в хронологической последовательности.
Решил не создавать новую тему, эта вполне подходит по названию.
Читаем документацию QLua.chm :
Цитата
SetValue Функция предназначена для установки указанного значения на выбранной линии определенной свечи индикатора: Формат вызова: BOOLEAN SetValue(NUMBER index, NUMBER line_number, NUMBER value) Параметры:
index – индекс свечи;
line_number – номер линии;
value – индекс первой свечки. Первая (самая левая) свечка имеет индекс 0.
Ясно, что value – это не индекс первой свечки, а значение, которое мы устанавливаем. Однако, эта "опечатка" - еще не беда.
Беда в том, что из следующего за этим предложения "Первая (самая левая) свечка имеет индекс 0." легко можно прийти к выводу, что для функций SetValue, GetValue и SetRangeValue нумерация свечей индикатора начинается с 0. В то же время несложный тест показывает, что это не так - нумерация на самом деле начинается с 1. На всякий случай прошу разработчиков разъяснить - это действительно ошибка в документации или же ошибка в работе перечисленных функций? А также впоследствии прошу ее исправить.
Заметил также еще одну особенность работы функций SetValue и SetRangeValue - если с их помощью установить значения индикатора (индикатор рисовал в отдельном окне), которые выходят за границы минимальных/максимальных значений индикатора, установленных ранее с помощью return в OnCalculate, то новые значения в итоге не видны, так как оказываются за границами окна (автомасштабирование на такую смену значений индикатора не реагирует). Прошу исправить это в следующих версиях терминала.
sam063rus пишет: У нас уже есть раздел в меню: Свзязь->Списки. По идее, этого должно быть достаточного для квика, чтоб он понял, какие данные пользователю действительно нужны (на которые он каГбе "подписан"). Зачем было делать ещё привязку к открытым таблицам ТВС
Этот раздел влияет на получаемые параметры (которые отображаются, например, в Текущей таблице параметров). Список инструментов, по которым происходит получение обезличенных сделок, задается в пункте меню "Связь / Заказ всех сделок". В свою очередь настройки, которые отображаются при выборе этого пункта меню, могут меняться в зависимости от настроек открытых на текущий момент ТВС и тиковых графиков.
Цитата
sam063rus пишет: Таблица всех сделок пуста НО!!! приходит куча колбеков аж со вчерашней вечерней сессии и заканчивая сегодняшней.
Проверьте настройки в "Связь / Заказ всех сделок" - возможно, там включено получение сделок по классам Фьючерсы или Опционы FORTS (дополнительная сессия). Также название этих классов может содержать в скобках слова "история пред. вечерней сессии".
Серж пишет: колбеки будут вызываться только после выхода из функции OnInit
А где об этом написано? Или это следует из того, что OnInit и колбеки выполняются в основном потоке терминала, поэтому пока не отработает OnInit ничего другое выполняться не будет?
И, насколько я понимаю, в вашем варианте для новых свечей, которые успеют добавиться в источник данных за время от начала до конца работы цикла, колбэк уже не будет вызван никогда, т.е. они выпадут из обработки.
Есть еще правда ненулевая вероятность того, что пока будет выполняться цикл for i = 1, ds:Size() do с сервера успеют поступить новые свечи, которые не были учтены ранее в ds:Size(). Поэтому ds:SetUpdateCallback(GetPrice) наверное лучше поместить до цикла чтения свечей из источника данных.
function OnInit(script_path)
local function GetPrice(index)
Candles[index] = ds:C(index)
end
ds = CreateDataSource(ClassCode, SecCode, Interval)
for i = 1, ds:Size() do
Candles[i] = ds:C(i)
end
ds:SetUpdateCallback(GetPrice)
end
Иначе коллбэк будет вместо обновления данных при каждом вызове полностью сканировать источник данных от самого начала до конца.
А описание функции GetPrice(index) поместил на всякий случай впереди, чтобы интерпретатор Луа не тратил время на разбор ее описания между окончанием чтения источника данных и установкой коллбэка.
Дмитрий пишет: А есть способ получать данные свечей с графика, не сохранив ни в какой переменной таблицу data_source, которую возвращает CreateDataSource ?
Здравствуйте, Без таблицы это значит на прямую с графика. Для этого есть функция getCandlesByIndex.
Я имел в виду без использования getCandlesByIndex, а именно после вызова CreateDataSource и SetUpdateCallback. Я подумал, что Серж, возможно, как-то получает эти данные внутри колбэка, не сохраняя при этом в переменной таблицу data_source, которую вернула функция CreateDataSource.
Здравствуйте! Суть пожелания в теме. Хотелось бы еще, чтобы новый размер окна запоминался после его закрытия и использовался при повторном открытии. Окно по умолчанию небольшое, из-за чего иногда приходится прокручивать список скриптов, что не слишком удобно. Или хотя бы просто увеличьте размеры этого окна по умолчанию.
Серж пишет: Задача: рассчитать индикатор по данным с графика. Устанавливаем колбек CreateDataSource(ClassCode, SecCode, Interval):SetUpdateCallback(fCB). В ответ приходят данные всех свечей с графика, по которым заполняем таблицу Candles[index].
Но! Если открыт график по данной бумаге, то в колбек приходят только данные с момента установки колбека.
Решение? (getCandlesByIndex не интересует)
Код
ds = CreateDataSource (ClassCode, SecCode, Interval)
for i = 1, ds:Size() do -- не уверен, что тут нумерация начинается с 1, а не с 0
Candles[i] = ds:C(i)
end
Здравствуйте! Также обнаружил, что любой вызов функции getScriptPath() в скрипте индикатора (и вообще любого скрипта, находящегося в папке LuaIndicators) приводит к зависанию терминала при попытке открыть окно добавления индикатора на график, но только в том случае, если вызов getScriptPath() производится не внутри какой-либо другой функции (типа Init(), OnCalculate() и т.п.). Версия терминала 6.16.0.42
Роман пишет: getSecurityInfo(getSecurityInfo("","RIM5").class_code,"RIM5")
кстати, а какой смысл пытаться получить код класса с помощью getSecurityInfo, чтобы затем передать этот код в качестве параметра той же самой функции getSecurityInfo?
И учтите, что инструмент с одним и тем же кодом может присутствовать в нескольких классах. В этом случае getSecurityInfo вернет вам код первого попавшегося класса, где есть такой инструмент. И не факт, что это будет именно тот самый класс, который нужен вам.
Шаг цены для фьючерса на индекс РТС равен 10: http://moex.com/ru/contract.aspx?code=RTS-6.15 getSecurityInfo(getSecurityInfo("","RIM5").class_code,"RIM5").scale возвращает количество значащих цифр после запятой, а не шаг цены
Zoya Vdovina пишет: Если к первой ТВС добавляем вторую, при этом устанавливаем фильтр на другой класс и одну бамагу, в первую ТВС поступают данные и во вторую ТВС так же поступают данные согласно фильтру. В Связь/Заказ всех сделок фильтры не пропадают.
А вы включите получение всех сделок целиком по классу (не фильтруя отдельные инструменты), а затем откройте новую ТВС, в которой установлен фильтр по одному инструменту их того класса, по которому уже идет получение сделок в первой таблице. Тогда в окне "Связь / Заказ всех сделок" на данном классе также появится фильтр по этому единственному инструменту, в результате сделки по остальным инструментам данного класса в первую ТВС поступать перестанут.
Sergey Gorokhov пишет: Порядок данных в хранилище терминала, всегда соответствует порядку загрузки данных с сервера. А порядок данных в визуальной таблице всегда соответствует порядку на сервере QUIK (если не настроено иное)
А чему соответствует порядок строк в файле, созданном с помощью пункта контекстного меню визуальной таблицы всех сделок "Сохранить в файл обезличенные сделки из таблицы", а также пункта "Сохранить в файл все обезличенные сделки"?
s_mike@rambler.ru пишет: Никогда нельзя полагаться, что содержимое строки с номером N для таблицы всех сделок (и иных таблиц) будет неизменным в течение сессии?
Да, такое может быть при докачке данных
Sergey Gorokhov, Вы имели в виду физический номер строки, на который ссылаемся при обращении к таблице всех сделок с помощью функции getItem, или номер строки в таблице всех сделок, которую мы видим на экране?
Danial Novikov пишет: Скажите, а как её тогда использовать? И как мне получить значение цены фьючерса RIM5 ?
Я знаю что данные с любого графика можно получать с помощью функции getCandlesByIndex , но она требует, чтобы это график был открыт и у него был назначен идентификатор, что очень неудобно.
Если вы делаете индикатор, то график у вас по определению будет открыт, ведь индикатор работает только при добавлении на график. Для получения значений с графика, на который добавляете индикатор, используйте функции, описанные здесь: http://help.qlua.org/ch13_2_4.htm
Здравствуйте! У меня в терминале открыта таблица всех сделок, отображающая сделки по всем инструментам ряда классов. В настройках "Связь / Заказ всех сделок" напротив этих классов стоят галочки, фильтры по отдельным инструментам не установлены. Уже давно начал замечать, что иногда настройки в окне "Связь / Заказ всех сделок" по непонятной причине слетают, в результате чего вместо получения сделок по целому классу идет заказ сделок только по одному инструменту из этого класса, так как там самопроизвольно устанавливается фильтр. Долго не мог понять причину этого, но наконец удалось обнаружить, что фильтр по одному определенному инструменту в окне "Связь / Заказ всех сделок" устанавливается автоматически в том случае, если я открываю новую таблицу всех сделок, в которой устанавливаю фильтр именно по этому инструменту. И даже несмотря на то, что в терминале остается открытой предыдущая таблица всех сделок, в которой должна выводиться информация по всем инструментам данного класса, получение этой информации прекращается из-за автоматической установки фильтра в окне "Связь / Заказ всех сделок". По-моему, такое поведение программы иначе, как ошибкой, назвать нельзя. Прошу исправить эту ошибку, то есть сделать так, чтобы заданный ранее список выбранных классов (и/или инструментов) в окне "Связь / Заказ всех сделок" не ограничивался автоматически ни при каких обстоятельствах.
Добавить в функцию getQuoteLevel2() дополнительный возвращаемый параметр datetime, Вызывая функцию getQuoteLevel2() хотелось бы точно знать время когда произошли изменения в стакане, не привязываясь к локальному времени на клиенте.
Добрый день! Тогда для полноты картины было бы логично добавить datetime в функции getParamEx и OnParam, чтобы точно знать, когда на самом деле параметр получил новое значение. Зарегистрируйте, пожалуйста, такое пожелание.
s_mike@rambler.ru пишет: Ну будет вам... Берите готовое и экспортируйте историю параметров
Спасибо, но из сохраненных Вашим скриптом данных об изменениях отдельных параметров (когда таких изменений несколько в пределах одной секунды) точно так же невозможно собрать достоверную таблицу истории изменений параметров, по причинам, описанным выше в этой ветке, а также по этой ссылке: https://forum.quik.ru/forum10/topic110/
Michael Bulychev пишет: На данный момент в Lua мы отдали все что смогли. Проблема не забыта и мы постараемся дать доступ из lua к таблице истории изменений параметров.
Если для вас вместо доработки QLua будет проще реализовать возможность ручного сохранения в файл содержимого Таблицы изменений параметров точно в том виде, в каком она отображается на экране, то сделайте, пожалуйста, хотя бы это для начала. Соответствующее пожелание у вас уже вроде как зарегистрировано под номером CQ01579578. Существующие на данный момент средства сохранения этой таблицы через буфер обмена или DDE не работают при большом количестве столбцов или строк из-за нехватки памяти (https://forum.quik.ru/forum1/topic58/). Как сообщила мне ваша служба техподдержки, эту проблему невозможно решить без перехода на 64-разрядную версию терминала. Поэтому желание построить такую таблицу с помощью средств QLua лично у меня появилось, как говорится, не от хорошей жизни.
Stanislav Tvorogov пишет: Эти значения параметров необходимо использовать как раз для клиентов типа "МД". Для всех остальных необходимо использовать функцию getBuySellInfo() с параметрами "is_margin_sec" и "is_asset_sec".
Поэтому я как раз и просил дать четкое описание того, как правильно определять тип клиента с помощью функции getBuySellInfoEx()
Цитата
Дмитрий пишет: я думал, что в параметре client_type STRING Тип клиента будет возвращено значение "МД", а на самом деле там стоит значение "4".
В документации не сказано, что для клиентов типа "МД" значение параметра client_type должно быть равно "4".
Цитата
Дмитрий пишет: То есть, хотелось бы понять - так и должно быть или это ошибка?
А если так и должно быть (для типа клиента "МД" : client_type = "4"), то возникает вопрос - может ли получиться так, что это условие перестанет выполняться в одном из следующих случаев: 1) при изменении каких-то внутренних справочников на сервере у брокера 2) при смене версии терминала
Stanislav Tvorogov пишет: Для получения информации о возможности покупки бумаги в лонг или шорт следует использовать параметры "is_long_allowed" и "is_short_allowed", полученные через функцию getBuySellInfoEx().
Это значит, что значения параметров is_long_allowed и is_short_allowed, полученных при вызове функции getBuySellInfoEx(), нужно использовать во всех случаях, а не только для клиентов типа «МД» ? То есть, значения этих параметров будут корректными для всех типов клиентов, поэтому тип клиента (client_type) проверять в данном случае не нужно ?
latrop1 пишет: Никакого кода не нужно, проблема проявляется в стандартном интерфейсе Квика. Если на одно окно диаграммы бросить пару графиков параметров, напр, "кол-во сделок" и "цену последней", то при тиковом интервале графики окажутся не корректно синхронизированными.
Согласен, эту ошибку в работе терминала я тоже заметил уже давно на графиках, а затем уже обнаружил подобную проблему и при попытке сопоставить данные по двум параметрам с помощью QLua.