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

 
Ihor Herasko:


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

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

Индикаторы бывают разные. Тормознутые тоже. И не все — свои и в исходниках.

Про пару секунд улыбнуло. В интерфейсе чувствуются десятки миллисекунд, сразу появляется дискомфорт.

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

 
Andrey Khatimlianskii:

Индикаторы бывают разные. Тормознутые тоже. И не все — свои и в исходниках.

Про пару секунд улыбнуло. В интерфейсе чувствуются десятки миллисекунд, сразу появляется дискомфорт.

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


Я обычно глобальные переменные не использую, но иногда встречается такое. 

При работе с глобальными переменными получается чехарда. При удалении индикатора с графика нужно почистить за собой и удалить глобальные переменные. В каком месте индикатора вы будете удалять глобальные переменные? Наверное удалять нужно в Deinite, другого места не придумать. Так вот при смене таймфрейма и создания новых переменных приходит деинит и всё стирает. Получается что Глобальные Переменные нельзя использовать в индикаторах.

 
Sergey Chalyshev:


Я обычно глобальные переменные не использую, но иногда встречается такое. 

При работе с глобальными переменными получается чехарда. При удалении индикатора с графика нужно почистить за собой и удалить глобальные переменные. В каком месте индикатора вы будете удалять глобальные переменные? Наверное удалять нужно в Deinite, другого места не придумать. Так вот при смене таймфрейма и создания новых переменных приходит деинит и всё стирает. Получается что Глобальные Переменные нельзя использовать в индикаторах.

Сергей, есть реальный не высосанный из пальца пример? Придумать я тоже могу, но на практике не сталкивался с проблемами.

ps: глобальные переменные тоже можно именовать в зависимости от ТФ.

 
Andrey Khatimlianskii:

Индикаторы бывают разные. Тормознутые тоже. И не все — свои и в исходниках.

Про пару секунд улыбнуло. В интерфейсе чувствуются десятки миллисекунд, сразу появляется дискомфорт.

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

на 3 стр я приводил пример из практики:
Первое что вспоминается - у меня в деинит происходит запоминание в глоб. переменные предыдущего состояния (нажатых/отжатых кнопкок) а потом в инитах происходит установка кнопок по сохраненным значениям. И вот именно кнопки у меня не всегда правильно переустанавливаются. Это первое, что вспомнил, может что-то еще найду...
 
elibrarius:
на 3 стр я приводил пример из практики:

запоминайте в гл. терминала при каждом изменении соответстующих переменных, а не при инит/деинит.
 
Andrey Dik:

запоминайте в гл. терминала при каждом изменении соответстующих переменных, а не при инит/деинит.

Запомню)
А еще надо запомнить, что в текущей реализации терминала в Deinit вообще ничего нельзя делать, что потом должно использоваться (ни в глоб. переменные, ни в файлы писать)...

по сути бесполезная финкци стала, при такой нарушенной последовательности.

Я то запомню, (хорошо что случайно натолкнулся на эту ветку), а вот другие программисты (которые сюда не заглянут) так и будут пользуясь естественной логической последовательностью и пользоваться деинитом надеясь, что он отработает, а уже потом запустится инит на новом ТФ.

 
elibrarius:

Запомню)
А еще надо запомнить, что в текущей реализации терминала в Deinit вообще ничего нельзя делать, что потом должно использоваться (ни в глоб. переменные, ни в файлы писать)...

по сути бесполезная финкци стала, при такой нарушенной последовательности

Просто поймите, что бывает ещё и другая логика. Логика разработчиков МТ в частности. Согласно этой, другой логике всё выглядит вполне логично. Отсюда вывод: подстраивайтесь под эту логику и не пытайтесь переубедить людей, которые наверное по-опытней вас в этом. Бесполезно... Ради одного индикатора менять сложившуюся логику никто не согласится.
 
Ну не у меня первого такая проблема, так что не ради одного индикатора. Для себя я уже все переделал, а вот другие могут тоже наступать на эти грабли. Не лучше ли грабли просто убрать, чтобы никто на них больше не наступал?
 
Alexey Viktorov:
Просто поймите, что бывает ещё и другая логика. Логика разработчиков МТ в частности. Согласно этой, другой логике всё выглядит вполне логично. Отсюда вывод: подстраивайтесь под эту логику и не пытайтесь переубедить людей, которые наверное по-опытней вас в этом. Бесполезно... Ради одного индикатора менять сложившуюся логику никто не согласится.


Если бы это не было связано с финансами, возможно не было бы и таких обсуждений.

А так как от одного или другого  индикатора зависит советник торговли, который просто перестанет работать правильно из за простого переключения ТФ. Вот, что больше всего напрягает. 

Как же ему можно доверить финансы?

Возможно наши мнения и расходятся в этом вопросе с разработчиками МТ.
 
Andrey Khatimlianskii:

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

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

Ребята, вы все путаете много разных вещей. Давайте сойдемся во мнении хотя бы относительно двух требований к терминалу как критически важному софту:

- он должен работать предсказуемо, строго следуя одной и той же логике (даже при наличии многопоточности);

- он должен работать быстро.

(не суть важно, знает ли копия индикатора о других копиях, однако важно, что глобальные данные, порученные для хранения терминалу, должны сохранять консистентнность - это забота терминала, а не каждого отдельного взятого разработчика индикатора)

Дальше вопрос - как это реализовать. Сейчас реализовано только с прицелом на требование 2. Я предлагаю реализовать с учетом требования 1, без ущерба для 2.

Никаких заметных тормозов не будет, если обратить внимание, что события инит/деини чарта и инит/деини индикатора - это разные вещи. Чарт сразу покажет основной новый график, но для унаследованных индикаторов событие OnInit будет поставлено в очередь после обработки предыдущего OnDeinit. Очереди событий в терминале и так есть.

Если MQ пожелает, может прислать мне на своих условиях NDA диаграммы классов и последовательностей, я поправлю их ;-).