Вызов getDataSourceInfo() из Init() в Lua индикаторах

Страницы: 1
RSS
Вызов getDataSourceInfo() из Init() в Lua индикаторах
 
Добрый день!

При написании своего специфического индикатора иногда возникает необходимость делать некоторые начальные настройки в его работе в зависимости от того, для какого инструмента он строится.
Однако, из Init() вызывать getDataSourceInfo() бессмысленно (мы получим информацию только о тайм-фрейме). Перезапускать рабочее место Quik после добавления индикатора на график, как указано в "Руководстве пользователя QLua" как-то не хочется.
(На самом, деле нужно как-то заставить Quik повторно вызвать Init() индикатора, что можно, впрочем, сделать и без перезапуска рабочего места, а просто некоторыми манипуляциями с самим окном графика. Но это тоже не выход).

Что посоветуете?

Первое, что мне самому приходит в голову, это выполнить нужные настройки при первом же вызове OnCalculate().
getDataSourceInfo() здесь уже будет работать корректно, т.к. к этому моменту Quik уже "привязал" новый индикатор к источнику данных.
Но это тоже не самый красивый ход: каждый раз проверять индекс, отлавливая именно первую свечку, чтобы не заниматься настройками вообще при каждом вызове OnCalculate() и т.д.

Вопрос к разработчикам: я так понимаю, что, при добавлении Lua индикатора на график, Init() вызывается до "подключения" к источнику данных. А что мешает его вызвать после? Так ли важно знать количество линий на индикаторе до "подключения" к источнику данных? Если обеспечить корректную работу getDataSourceInfo() при первом после добавления индикатора на график вызове Init() все же нельзя, то хотел бы попросить разработчиков добавить дополнительный СallBack, типа Init2() после "подключения" к источнику данных, но до первого вызова OnCalculate(). Можно, например, это делать не для каждого индикатора, а только если Init() вернет "соответствующую просьбу".
 
Здравствуйте,
Задача вполне решается проверкой первой свечи в OnCalculate
Из приведенного описания не вполне понятно, чем данный подход не устраивает.
 
Здравствуйте,
Это то понятно, что решить задачу можно, отлавливая вызов для первой свечки, но это лишние накладные расходы, пускай и мизерные. А на медленных машинках, для процессов, исполняемых интерпретатором, если кто-то решит повесить много индикаторов, в каждом из которых по несколько линий ...:), уже можно заметить подтормаживания.

Но не в этом суть.
Не прослеживается единообразия в логике вызовов Init() со стороны Quik: при исходном добавлении индикатора на график, Init() вызывается до привязки к источнику данных, а при замене инструмента Init(), почему-то, вызывается уже после привязки к новому инструменту.
 
Цитата
Алексей написал:
Не прослеживается единообразия в логике вызовов Init() со стороны Quik: при исходном добавлении индикатора на график, Init() вызывается до привязки к источнику данных, а при замене инструмента Init(), почему-то, вызывается уже после привязки к новому инструменту.
При добавлении индикатора сразу указывается Источник данных. Поэтому описанное поведение больше похоже на ошибку в логике.
 
Цитата
Старатель написал:
Цитата
Алексей   написал:
Не прослеживается единообразия в логике вызовов Init() со стороны Quik: при исходном добавлении индикатора на график, Init() вызывается до привязки к источнику данных, а при замене инструмента Init(), почему-то, вызывается уже после привязки к новому инструменту.
При добавлении индикатора сразу указывается Источник данных. Поэтому описанное поведение больше похоже на ошибку в логике.
В том-то и дело, что при вызове getDataSourceInfo() из Init() Вы не получите информацию об инструменте, на основе свечек которого должен строиться индикатор. На это даже сами разработчики Quik указывают в  "Руководстве пользователя QLua". Имеется в виду самый первый вызов Init() непосредственно после добавления индикатора в окно графика.

To: Старатель.
Под "привязкой" я имею в виду не действия пользователя, естественно указавшего для какого инструмента он желает видеть индикатор, а инициализацию внутренних служебных таблиц о самом инструменте, а также о ds (DataSource) с информацией о свечках, о методах H L O C V Size тд., которую Quik в вышеописанном случае производит уже только после вызова Init().
 
Цитата
Алексей написал:
Это то понятно, что решить задачу можно, отлавливая вызов для первой свечки, но это лишние накладные расходы, пускай и мизерные. А на медленных машинках, для процессов, исполняемых интерпретатором, если кто-то решит повесить много индикаторов, в каждом из которых по несколько линий ...:),

1) То что проверка первой свечи приводит к "накладным расходам" не более чем просто слова.
2) Гипотетическое создание Init2 совершенно никак не позволит изменить ситуацию. И даже если ее добавить, это будет ровно тоже самое что проверка первой свечи.
3) Решение в виде проверки первой свечи, в полной мере решает задачу и аргументов которые не позволят ее решить указанным способом, Вы так и не привели.
 
Цитата
Sergey Gorokhov написал:
Цитата
Алексей   написал:
Это то понятно, что решить задачу можно, отлавливая вызов для первой свечки, но это лишние накладные расходы, пускай и мизерные. А на медленных машинках, для процессов, исполняемых интерпретатором, если кто-то решит повесить много индикаторов, в каждом из которых по несколько линий ...:),
1) То что проверка первой свечи приводит к "накладным расходам" не более чем просто слова.
2) Гипотетическое создание Init2 совершенно никак не позволит изменить ситуацию. И даже если ее добавить, это будет ровно тоже самое что проверка первой свечи.
3) Решение в виде проверки первой свечи, в полной мере решает задачу и аргументов которые не позволят ее решить указанным способом, Вы так и не привели.
отлавливание первой свечи оператором
if indx==1 then ... end
на медленных машинах займет не более  50 мкс.
А поступление очередных данных происходит не чаще, чем раз в  100 мс.
Разница примерно в 2000 раз.
А задержка реакции OC не менее 10 мс.
Разница в 200 раз.
А задержка отправки коротких сообщений с компа на сервер брокера типа заявок, может составить 200 мс
Разница примерно в 4000 раз.
За что боремся?
 
Цитата
Николай Камынин написал:
Цитата
Sergey Gorokhov   написал:
Цитата
Алексей   написал:
Это то понятно, что решить задачу можно, отлавливая вызов для первой свечки, но это лишние накладные расходы, пускай и мизерные. А на медленных машинках, для процессов, исполняемых интерпретатором, если кто-то решит повесить много индикаторов, в каждом из которых по несколько линий ...:),
1) То что проверка первой свечи приводит к "накладным расходам" не более чем просто слова.
2) Гипотетическое создание Init2 совершенно никак не позволит изменить ситуацию. И даже если ее добавить, это будет ровно тоже самое что проверка первой свечи.
3) Решение в виде проверки первой свечи, в полной мере решает задачу и аргументов которые не позволят ее решить указанным способом, Вы так и не привели.
отлавливание первой свечи оператором
if indx==1 then ... end
на медленных машинах займет не более  50 мкс.
А поступление очередных данных происходит не чаще, чем раз в  100 мс.
Разница примерно в 2000 раз.
А задержка реакции OC не менее 10 мс.
Разница в 200 раз.
А задержка отправки коротких сообщений с компа на сервер брокера типа заявок, может составить 200 мс
Разница примерно в 4000 раз.
За что боремся?
Я же нарисовал смайлик. И сразу далее написал, что естественно не в этом суть.
А суть вопроса к quik в том, что:

Не прослеживается единообразия в логике вызовов Init() со стороны Quik: при исходном добавлении индикатора на график, Init() вызывается до привязки к источнику данных, а при замене инструмента Init(), почему-то, вызывается уже после привязки к новому инструменту.
 
Цитата
Алексей написал:
Цитата
Николай  Камынин   написал:
Цитата
Sergey Gorokhov   написал:
Цитата
Алексей   написал:
Это то понятно, что решить задачу можно, отлавливая вызов для первой свечки, но это лишние накладные расходы, пускай и мизерные. А на медленных машинках, для процессов, исполняемых интерпретатором, если кто-то решит повесить много индикаторов, в каждом из которых по несколько линий ...  :)  ,
1) То что проверка первой свечи приводит к "накладным расходам" не более чем просто слова.
2) Гипотетическое создание Init2 совершенно никак не позволит изменить ситуацию. И даже если ее добавить, это будет ровно тоже самое что проверка первой свечи.
3) Решение в виде проверки первой свечи, в полной мере решает задачу и аргументов которые не позволят ее решить указанным способом, Вы так и не привели.
отлавливание первой свечи оператором
if indx==1 then ... end
на медленных машинах займет не более  50 мкс.
А поступление очередных данных происходит не чаще, чем раз в  100 мс.
Разница примерно в 2000 раз.
А задержка реакции OC не менее 10 мс.
Разница в 200 раз.
А задержка отправки коротких сообщений с компа на сервер брокера типа заявок, может составить 200 мс
Разница примерно в 4000 раз.
За что боремся?
Я же нарисовал смайлик. И сразу далее написал, что естественно не в этом суть.
А суть вопроса к quik в том, что:

Не прослеживается единообразия в логике вызовов Init() со стороны Quik: при исходном добавлении индикатора на график, Init() вызывается до привязки к источнику данных, а при замене инструмента Init(), почему-то, вызывается уже после привязки к новому инструменту.
А в квике как мультике про простоквашено (Письмо дяди Федора).
Начинал писать квик один писатель потом второй и т д.
Стратегию построения КВИКА разработали еще в прошлом веке.
Вот и нет однообразия.
А читатели - это клиенты брокеров.
 
еще замечу, что в init ставить настройку каких либо параметров не имеет смысла, так как он не вызывается при изменении параметров индикаторов.
Поэтому без проверки на 1 индекса Вы все рано не обойдетесь.
И смысла делать как вы хотите нет никакого.
 
Цитата
Николай Камынин написал:
еще замечу, что в init ставить настройку каких либо параметров не имеет смысла, так как он не вызывается при изменении параметров индикаторов.
Поэтому без проверки на 1 индекса Вы все рано не обойдетесь.
И смысла делать как вы хотите нет никакого.
Init() вызывается при:
1. Первоначальном добавлении индикатора на график,
2. При каждой смене тайм-фрейма (смена набора свечек при сохранении инструмента),
3. При каждой смене инструмента (смена источника данных для свечек).
4. На старте quik и, что по сути для индикатора тоже самое, при загрузке настройки окон из *.wnd

Так вот, при событиях 2, 3 и 4 getDataSourceInfo(), вызванная из Init() выдаст все корректную информацию и о новом тайм-фрейме, и новом инструменте.
Причем в "Руководстве пользователя QLua" прямо сказано, что только именно событие 4 гарантирует корректную работу getDataSourceInfo() при вызове из Init()

А вот в случае события 1, по непонятной причине, от getDataSourceInfo() мы можем получить только текущий тайм-фрейм окна графика.

Так чем же событие 1 так уж принципиально отличается от других, в особенности от события 4?
Почему во 2-4 случаях quik "подключает" новый инструмент к индикатору до вызова Init(), в случае 1 - после?
 
Простите, про событие 2 я погорячился, Init() не вызывается. Но сути дела это не меняет
 
Цитата
Николай Камынин написал:
Цитата
А в квике как мультике про простоквашено (Письмо дяди Федора).
Начинал писать квик один писатель потом второй и т д.
Стратегию построения КВИКА разработали еще в прошлом веке.
Вот и нет однообразия.
А читатели - это клиенты брокеров.
Ну в принципе, это многое объясняет :)
 
Вы говорили не об этом, но правильно ли я понял, что если код такой:
Код
int = getDataSourceInfo().interval
, то интервал будет получаться на каждой свечке.
А если такой:
Код
if index == 1 then
 int = getDataSourceInfo().interval
end
, то интервал будет получен единожды?
 
Цитата
Русский написал:
Вы говорили не об этом, но правильно ли я понял, что если код такой:
Код
  int  =   getDataSourceInfo ().interval  
, то интервал будет получаться на каждой свечке.
А если такой:
Код
   if  index  =  =   1   then 
 int  =   getDataSourceInfo ().interval
 end   
, то интервал будет получен единожды?
Да.
Но уточню:
getDataSourceInfo ().interval - это тайм-фрейм окна графика, в котором выводится индикатор. Это, строго говоря, не обязательно интервал по времени между предыдущей и текущей свечками, т.к. данные для каких-то моментов времени могут отсутствовать, и тогда предыдущая свечка может отстоять от текущей на больший, чем тайм-фрейм промежуток времени.
Проверять тайм-фрейм для каждой свечки не имеет смысла, т.к. если Вы смените тайм-фрейм, то quik перезапустит цикл вызовов OnCalculate() и первым делом вызовет OnCalculate(index = 1)
 
Алексей, благодарю.
 
Цитата
Sergey Gorokhov написал:
Здравствуйте,
Задача вполне решается проверкой первой свечи в OnCalculate
Из приведенного описания не вполне понятно, чем данный подход не устраивает.
Здравствуйте.
Расскажу чем не устраивает.. или подскажите как такое реализовать: обновление Settings из кода OnCalculate.

хочу в настройки по своей внутренней формуле вывести номер свечи от которой буду производить отрисовку. При этом пользователь имеет право вручную изменить номер свечи.
также хочу вывести в настройки некое значение рассчитанное из данных getDataSourceInfo (дать возможность пользователю изменить заранее рассчитанные значения) ,например, маржинальный диапазон или базовый интервал.

да можно рассчитать на первой свече все данные, но не записать их в Settings
function OnCalculate(i)

  -- определяем текущую бумагу и ее характеристики
  -- в Init можно разместить, но нужн перезапускать рабочее место
  if (i == 1) then
    sec_code   = getDataSourceInfo().sec_code
    class_code = getDataSourceInfo().class_code
    interval   = getDataSourceInfo().interval
    param      = getDataSourceInfo().param
          -- не прокатит!!!!
    Settings.Fx= F(sec_code, class_code, interval, param)


на текущий момент не представляю как такое сделать. по все той же причине нельзя изменять Settings вне Init.

Подскажите как реализовать описанное выше   в индикаторе.

п.с. перезагружать рабочее место или изменять настройки в индикаторе и затем еще раз его запускать... ну такое
Страницы: 1
Читают тему (гостей: 1)
Наверх