Последовательность выполнение Init() и DeInit() - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если идёт смена таймфрейма в пределах одного символа, то тут порядок инициализации-деинициализации в принципе предсказуем. Скачайте последний билд 1580 - там мы кое что поправили, теперь удаление индикаторов производится в самую последнюю очередь, поэтому не должно быть преждевременного деинита.
Индикаторы бывают разные. Тормознутые тоже. И не все — свои и в исходниках.
Про пару секунд улыбнуло. В интерфейсе чувствуются десятки миллисекунд, сразу появляется дискомфорт.
Не перевирайте. Речь не об интерфейсе, а о переходных процессах - переключении ТФ. На пустом графике переключение ТФ занимает бесконечно малое время? Нет. Значит, индикаторы не при чем.
А, главное, нет ответа на мой вопрос:
В каких ситуациях, кроме прямолинейной работы с граф. объектами (без названия ТФ в названии), важна последовательность ДеИнит - Инит?
Практически во всех ситуациях. Если речь идет, конечно, не об игрушках типа МАшек и подобных примитивах:
Согласен. Проблемы, кроме второй, решаемы, если знать о них. То есть всю логику теперь нужно запихнуть в OnCalculate, а Init и DeInit не использовать, написать свои. Только зачем они тогда нужны?
Во всяком случае речь о кроссплатформенности теперь вовсе не идет. Ведь у МТ4 и МТ5, как оказалось, разные подходы к Init и DeInit.
Если бы это не было связано с финансами, возможно не было бы и таких обсуждений.
А так как от одного или другого индикатора зависит советник торговли, который просто перестанет работать правильно из за простого переключения ТФ. Вот, что больше всего напрягает.
Как же ему можно доверить финансы?
Возможно наши мнения и расходятся в этом вопросе с разработчиками МТ.Вариантов решения этой проблемы масса. И почти все они были озвучены в этой теме.
1. Если по индикатору написан советник, то советник должен быть написан так, чтобы на него не влияла смена периода графика. Отсюда и не будет переинициализации индикатора.
2. Если надо в деините удалить графические объекты или изменить оформление чарта, то проверяйте причину деинициализации.
3. Если индикатору нужны какие-то параметры сохранять, то, как здесь было озвучено, сохраняйте эти данные не при деините, а тогда когда эти данные подготовлены или изменены.
4. Из двух кучек дерьма всегда выбирают ту которая меньше воняет. Соответственно выбирая между быстродействием от которого зависят ВСЕ индикаторы и сложностью сохранения каких-то данных в НЕСКОЛЬКИХ индикаторах я выбираю быстродействие.
Не понял. Пожалуйста, поясните. Деинит будет гарантированно после инита?
Если переключение таймфреймов идёт вниз, то сначала OnInit на младшем(новом) таймфрейме, а потом OnDeinit на старшем(старом) таймфрейме.
Если переключение идёт вверх, то всё наоборот. Сначала OnDeinit на младшем(старом) таймфрейме, а потом OnInit на старшем(новом) таймфрейме.
Тут нужно иметь в виду, что кеши обрабатываются от младшего таймфрейма к старшему
Скачайте последний билд 1580 - там мы кое что поправили, теперь удаление индикаторов производится в самую последнюю очередь, поэтому не должно быть преждевременного деинита.
:(( Млин, "обрадовали". Теперь возможно придется код переписывать в некоторых программах, потому как было заточено было как раз под "наоборот" - сначала Деюнит, а потом Юнит.
Странная, честно говоря, логика. Т.е. старая и новая копия индикатора однозначно будут жить какое-то время вместе, пока сначала не выполниться Юнит в новой копии индикатора , а вслед за этим Деюнит в старой. При этом нет возможности через Деюнит сообщить новой копии какую-либо информацию. Явно перемудрили. Ведь Юниты как правило гораздо более громоздки чем Деюниты. Зачем такая странная последовательность выполнения! Тогда эта тема будет возрождаться вновь и вновь. Вот если бы все же была возможность у программиста в индикаторе создавать некоторые переменные, которые не переинициализировались при смене ТФ, то и Бог бы с этой последовательностью OnInit и OnDeinit. Я уже пару раз об этом писал (1 и 2). Я согласен с логикой разработчиков, что в целях безопасности непозволительная роскошь для программистов указатели и ссылки, но создайте тогда механизм особого типа общих переменных для всех копий индикатора. Индикатор то один, своиства индикатора же тоже "где-то" храняться.
Если переключение таймфреймов идёт вниз, то сначала OnInit на младшем(новом) таймфрейме, а потом OnDeinit на старшем(старом) таймфрейме.
Если переключение идёт вверх, то всё наоборот. Сначала OnDeinit на младшем(старом) таймфрейме, а потом OnInit на старшем(новом) таймфрейме.
Тут нужно иметь в виду, что кеши обрабатываются от младшего к старшему
Ещё больше запутали.
Ведь если индикатором пользуется не сам автор, то переключать может как угодно и не дожидаясь выполнения инита и деинита? И что получится??? А если при одном варианте переключения в деините нужно предпринимать какие-то действия, то никому нет никакой разницы, будет это написано для одного направления переключения или для обоих направлений. Но зато для "тяжёлых" индикаторов добавили тормоза.
Ещё больше запутали.
Ведь если индикатором пользуется не сам автор, то переключать может как угодно и не дожидаясь выполнения инита и деинита? И что получится??? А если при одном варианте переключения в деините нужно предпринимать какие-то действия, то никому нет никакой разницы, будет это написано для одного направления переключения или для обоих направлений. Но зато для "тяжёлых" индикаторов добавили тормоза.
Где тормоза добавили? По сравнению с чем добавили?
Будьте добры свои утверждения подкреплять кодом, чтобы каждый мог воспроизвести
Ещё раз. Так как при смене символа-периода графика создаётся ещё одна копия индикатора, то порядок выполнения OnInit на новом символе-периоде и OnDeinit на старом символе-периоде неопределён
Где тормоза добавили? По сравнению с чем добавили?
Будьте добры свои утверждения подкреплять кодом, чтобы каждый мог воспроизвести
Ещё раз. Так как при смене символа-периода графика создаётся ещё одна копия индикатора, то порядок выполнения OnInit на новом символе-периоде и OnDeinit на старом символе-периоде неопределён
В этом сообщении
Если переключение таймфреймов идёт вниз, то сначала OnInit на младшем(новом) таймфрейме, а потом OnDeinit на старшем(старом) таймфрейме.
Если переключение идёт вверх, то всё наоборот. Сначала OnDeinit на младшем(старом) таймфрейме, а потом OnInit на старшем(новом) таймфрейме.
Тут нужно иметь в виду, что кеши обрабатываются от младшего таймфрейма к старшему
Вы сказали как есть или как сделали готовя новый билд?
Если как есть, то я не правильно понял и беру свои слова взад.
В этом сообщении
Вы сказали как есть или как сделали готовя новый билд?
Если как есть, то я не правильно понял и беру свои слова взад.
Это сделано в билде 1580
До этого деинициализация при смене таймфрейма почти всегда была раньше. Но только если переключение таймфреймов идёт вниз, то деинициализация производилась с кодом 1, а не 3, как должно быть
Это сделано в билде 1580
До этого деинициализация при смене таймфрейма почти всегда была раньше. Но только если переключение таймфреймов идёт вниз, то деинициализация производилась с кодом 1, а не 3, как должно быть
Как тогда обрабатывать эти коды деинициализации в Inite индикатора, для чего нужны эти коды? Ведь в индикаторе нет возможности подождать, Sleep не работает.