Последовательность выполнение Init() и DeInit() - страница 5

 
Nikolai Semko:


Да эт все понятно. Я про логику последовательности выполнения спрашивал. В том то и дело что ее нет. Иногда выполняется первым OnDeinit (как и положено согласно логике обывателя), а иногда первым OnInit.

Я понимаю, что ответ кроется в реплике "Какое-то время (очень короткое) обе копии индикатора существуют параллельно." Но от осознания этого вопрос этот не проясняется.

Положено, что бы в программе первым выполнялась функция OnInit.

Можете привести пример, когда не всегда выполняется последовательность OnInit -> OnDeinit?

 
Andrey Dik:

Положено, что бы в программе первым выполнялась функция OnInit.

Можете привести пример, когда не всегда выполняется последовательность OnInit -> OnDeinit?


Можете поюзать пример автора темы ERROR.mq5 , который он дает вначале. Попереключайте ТФ. и посмотрите во вкладке Эксперты что происходит.

 
Nikolai Semko:


Можете поюзать пример автора темы ERROR.mq5 , который он дает вначале

В течении дня поюзаю. А Вы лично поюзали уже?
 
Andrey Dik:
В течении дня поюзаю. А Вы лично поюзали уже?

Конечно, я еще юзал это 9 месяцев назад. Можете почитать мой коментарий под номером #8 в этой теме.
 
Stanislav Korotky:

Э, нет, тут не все так просто. Индикаторы сидят внутри другой сущности - график/чарт, и подчинены ей (я в курсе про их сложные отношения один ко многим, но сути это не меняет). У графика есть свой цикл жизни, включающий некие внутренние события инит и деинит, которые являются границами для цикла жизни индикаторов. Иными словами, индикатор не может пережить свой график. Деинит графика должен дождаться деинита или таймаута деинита всех индикаторов. Только затем может запускаться инит графика для нового таймфрейма, и из него - вызов инитов вложенных индикаторов.

Графики - это те же индикаторы. Индикаторы могут "пережить" свои графики.

До OnInit индикатора/советника выполняются конструкторы глобальных объектов. После OnDeinit - деструкторы. Поэтому OnInit и OnDeinit можно выкинуть из любого индикатора.

Проблема лишь не в совпадении своих представлений об индикаторах с реальностью. Наверное, такое поведение критично для некоторых фрилансеров, не способных написать решение.

Буду приветствовать шаг навстречу по данной теме со стороны разработчиков. Но тут столкнулись две полностью понимаемые друг друга точки зрения со СВОЕЙ логикой, как должно быть. Ни одна из них не ущербней другой. Просто одни считают правильным так, другие - этак.

 

Представьте себе, как тормозили бы графики, если бы перед сменой ТФ терминал ждал выгрузки всех индикаторов со старого ТФ, и только потом строил и инициализировал новый.

В каких ситуациях, кроме прямолинейной работы с граф. объектами (без названия ТФ в названии), важна последовательность ДеИнит - Инит?

 
Andrey Khatimlianskii:

Представьте себе, как тормозили бы графики, если бы перед сменой ТФ терминал ждал выгрузки всех индикаторов со старого ТФ, и только потом строил и инициализировал новый.

В каких ситуациях, кроме прямолинейной работы с граф. объектами (без названия ТФ в названии), важна последовательность ДеИнит - Инит?


+
 

Ещё раз повторяю. При смене таймфрейма или символа у графика создаётся новая копия индикатора. Новая.

По той самой причине, что расчётные части индикаторов живут в кешах истории. Для каждого таймфрейма - свой кеш баров. При смене таймфрейма скажем EURUSD,M1 на EURUSD,H1, индикатору в кеше M1 посылается событие Deinit с причиной 3 (chart change) и через некоторое время этот индикатор выгружают. Если вдруг этот индикатор не успел обработать Deinit с причиной 3, то при выгрузке уже будет деинициализация с причиной 1 (chart close). Если кеша H1 к данному моменту не существовало, то он создаётся. После этого к кешу H1 загружается НОВАЯ копия индикатора, которому посылается событие Init. Новая копия индикатора ничего не знает про предыдущую копию, которая вот-вот умрёт. У новой копии индикатора все переменные чистенькие, только что родившиеся.

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

Поэтому совет для топик-стартера. Ориентируйтесь на причину деинициализации. Если она равна 3, то не надо возвращать цветовую схему графику

 
А нельзя ли при смене ТФ дождаться всех Deinit, а уже потом запускать индикаторы и выполнять в них Init?
 
Andrey Khatimlianskii:

Представьте себе, как тормозили бы графики, если бы перед сменой ТФ терминал ждал выгрузки всех индикаторов со старого ТФ, и только потом строил и инициализировал новый.

В каких ситуациях, кроме прямолинейной работы с граф. объектами (без названия ТФ в названии), важна последовательность ДеИнит - Инит?


Почему они будут тормозить? Разве что индикатор криво написан. У нормально написанного индикатора DeInit занимает достаточно малое время. Более того, переключение ТФ - не такая уж и частая операция. В некоторых особо тяжелых случаях (это к "неправильным" индикаторам) можно и подождать секунду-другую при смене ТФ. 

Поэтому довод о торможении при переключении ТФ более чем сомнителен. К тому же при переключении на тот ТФ, который еще не был построен, также обнаруживается достаточно ощутимая задержка по времени. И никто не плачет о тормозах терминала.

Причина обращения: