Последовательность выполнение Init() и DeInit() - страница 10
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я же четко написал - держите необходимые для передачи в копию данные всегда актуальными, не нужно это делать только при ините, всегда держите актуальными.
Андрей, Вы что прикалываетесь что-ли, или реально не понимаете, что все ваши актуальные данные, которые хранятся в переменных и массивах в индикаторах при смене ТФ становяться неактуальными из-за уничножения копии индикатора со всеми его потрахами. В экспертах конечно то все просто, т.к. там нет переинициализации.
Андрей, Вы что прикалываетесь что-ли, или реально не понимаете, что все ваши актуальные данные, которые хранятся в переменных и массивах в индикаторах при смене ТФ становяться неактуальными из-за уничножения копии индикатора со всеми его потрахами. В экспертах конечно то все просто, т.к. там нет переинициализации.
Нет, не прикалываюсь.
Вы не понимаете о чем я сказал.
К примеру, есть некий набор данных, который необходимо передать в другую копию индикатора (будь то ещё один индикатор брошенный на чарт или новая копия индикатора при смене ТФ это не важно). Индикатор что то там себе считает, каждый раз что он что то посчитал и при этом это что то предназначается для расшаривания на другие индикаторы, этот индикатор должен обновить. Каждый раз. Эту базу данных можно хранить в разных местах в зависимости от объёма данных и требуемой скорости обмена данными. Обновление этих данных нужно делать при каждом необходимом случае после изменения этих данных, а не только при деинтите. Вот и весь фокус. Ничего сложного. Нет речи о хранении данных в локальных переменных индикатора, речь о том, что бы скидывать/обновлять данные каждый раз как эти данные были пересчитаны.
А с графическими объектами совсем просто. даже нет необходимости разжёвывать.
В экспертах конечно то все просто, т.к. там нет переинициализации.
Нет, не прикалываюсь.
Вы не понимаете о чем я сказал.
К примеру, есть некий набор данных, который необходимо передать в другую копию индикатора (будь то ещё один индикатор брошенный на чарт или новая копия индикатора при смене ТФ это не важно). Индикатор что то там себе считает, каждый раз что он что то посчитал и при этом это что то предназначается для расшаривания на другие индикаторы, этот индикатор должен обновить. Каждый раз. Эту базу данных можно хранить в разных местах в зависимости от объёма данных и требуемой скорости обмена данными. Обновление этих данных нужно делать при каждом необходимом случае после изменения этих данных, а не только при деинтите. Вот и весь фокус. Ничего сложного. Нет речи о хранении данных в локальных переменных индикатора, речь о том, что бы скидывать/обновлять данные каждый раз как эти данные были пересчитаны.
А с графическими объектами совсем просто. даже нет необходимости разжёвывать.
Очень спорный вопрос про ничего сложного. Попробуйте реально повторить на примере простой машки, то что я реализовал в этом продукте. В машке вы меняете период с помощью мышки, и потом при смене ТФ изменения должны сохраниться, причем в окне возможно использовать несколько таких индикаторов. И Вы поймете про ничего сложного. А если нужно передать массив. И Вы поймете, насколько это "просто". Возможно я бы и сам так думал, если бы не реализовывал это уже.
Очень спорный вопрос про ничего сложного. Попробуйте реально повторить на примере простой машки, то что я реализовал в этом продукте. В машке вы меняете период с помощью мышки, и потом при смене ТФ изменения должны сохраниться, причем в окне возможно использовать несколько таких индикаторов. И Вы поймете про ничего сложного. А если нужно передать массив. И Вы поймете, насколько это "просто"
Я только недавно узнал, что в советниках при переинициализации все переменные сохраняются, т.е. писал советники так же. как и индикаторы подразумевая, что программа ничего не знает о других программах, для неё существет только их инит и деинит, о чужих инит и деинит программа знать не должна.
Поэтому я никогда не закладывался на последовательность во времении инит и деинит выгружаемой и запускаемой вновь программы, я привык никогда по возможности не полагаться на то, что кода нибудь это может изменится (в 1580 вот изменилось). Если закладываться на недокументированные баги и фьючи платформы, то это может в будущем встать боком.
В моей практике тоже есть продукты с динамическим изменением визуализации в зависимости от действий пользователя, применяю всё - начиная с событий и заканчивая обменом через файлы. При этом на чарте индикаторов гораздо больше чем 1 как правило, ещё благо что индикаторных буферов в 5-ке неограниченное количесвто и можно создавать буферы как параметр при запуске. Т.е. мы же творческие люди, нужно иметь гибкий подход к решению наших задач и при этом держать в голове специфику 3-х видов программ, а разработчики платформы озабочены другими вопросами, которые более важны чем мелкие трудности по сравнению с глобальными задачами платформы.
Есть действительно важные недочеты платформы, о которых говорят не много или вообще не говорят, это гораздо важнее чем надуманная проблема "очерёдности инитов и деинитов".
Если переключение таймфреймов идёт вниз, то сначала OnInit на младшем(новом) таймфрейме, а потом OnDeinit на старшем(старом) таймфрейме.
Если переключение идёт вверх, то всё наоборот. Сначала OnDeinit на младшем(старом) таймфрейме, а потом OnInit на старшем(новом) таймфрейме.
Тут нужно иметь в виду, что кеши обрабатываются от младшего таймфрейма к старшему
Это просто ужас. Прикладные программисты не должны думать о таких системных вещах. Платформа может внутри себя обрабатывать кеши как хочет, но на уровне MQL должна прозрачно приводить все к единому контракту событий без потенциальных побочных эффектов. Все отсылки к яко-бы соображениям эффективности и возможностям всем и каждому самостоятельно обходить проблему - просто несостоятельны. Можно сделать и эффективно и удобно (вообще исключив возможность наступить на эти грабли), единожды и навсегда.
Правильно, не должны. Ну вот запускаете к примеру Total Commander. Зачем требовать у Microsoft, что бы Windows позаботилась о "правильной" последовательности выгрузки/закрузки копий TC в оп.память? Разве это забота OS?
Забота OS что бы TC не мешал другим TC, а уж что они там в оп.памяти делают, файлами обмениваются или ещё чем то поинтимнее - это их, программ, дело.
"Я так думаю!" (с) Мимино, 1977г.
Хочется подвести промежуточный итог и резюмировать все вышесказанное. Итак до выхода 1580 билда МТ5 (текущий билд 1571) что мы имеем.
В индикаторах, в отличии от советников, при смене ТФ в виду того, что "создаётся новая копия индикатора, которая ничего не знает о предыдущей копии", происходит переинициализация всех переменных, кроме того порядок выполнения OnDeinit старого ТФ и OnInit нового ТФ непредсказуем вне зависимости от переключения ТФ "вверх" или "вниз"(практика пока противоречит сказанному ув. Славой) . В связи с этим у программистов возникает ряд проблем и неопределенностей. Например:
- программер, который не читал эту тему при создании индикатора для чего-то в OnInit создает какой-либо объект, логично делая проверку перед его созданием на существование объекта с таким именем. Также, что тоже логично, он прописывает удаление данного объекта в OnDeinit. При смене ТФ если первым выполняется OnInit нового ТФ, происходит проверка на существование объекта, выясняется что он уже существует, и он не создается, т.к. уже создан. После чего выполняется ОnDeinit старого ТФ и объект удаляется. Программист в ступоре. Где мой объект, почему он удалился? Еще в больший ступор он впадет, когда в следующий раз при смене ТФ, когда последовательность выполнения OnInit и OnDeinit будет другая, объект не удалиться. То удаляется, то не удаляется.... После длительных исследований начнется обращение в Сервисдеск, новые темы на форуме о старом.
Это только самая простая ситуация. Будут и другие, т.к. эта особенность не описана в документации и об этом можно прочесть только на форуме.
Если же вам захочется создать что-нибудь эдакое и передавать некоторые параметры из старой копии индикатора новой при смене ТФ, то OnDeinit для этого использовать нельзя ввиду непредсказуемости последовательности выполнения операций инициализации и деинициализации. На мой взгляд самым оптимальным решением в этом случае является применение передачи данных(параметров) через ресурсы с использованием следующих инструментов: ResourceCreate на основе массива пикселей и ResourceReadImage, но это достаточно громоздко и необходимо будет позаботиться о безконфликтности ресурсов, если использовать несколько одинаковых индикаторов в одном окне, а также каждый раз когда меняются данные, которые надо передать для другой копии, необходимо сохранять их в непереинициализируемом ресурсе, т.к. время возможной смены ТФ для программы не известно в виду бесполезности использования OnDeinit. Я это уже давно реализовал (например в этом продукте), поэтому знаю, о чем говорю. Реализация передачи данных через файлы и через глобальные переменные терминала - это менее удачное решение (ИМХО).
Если с выходом нового билда 1580 будет все, как говорил Слава, то это не упростит, задачу, т.к. деинициализация старой копии индикатора будет происходить после инициализации новой копии. Но зато не будет неопределенности.
Стоит надеятся, что все же разработчики обратили внимание на эту проблему, раз пытаются что-то исправить.
Ждем новый билд.
Полностью согласен, что необходимо в документации ОБЯЗАТЕЛЬНО об этой особенности обработки упамянуть, иначе вновь прибывшие программеры будут с этим сталкиваться и приходить на форумы в поисках решения. (Зачем, если можно сразу об этом им сказать в доках на терминал и MQL)
Так же дописать в документации о том, что журнале не отображается полная картина происходящего а лишь его часть. Для полной картины смотрите в полных логах.
Об остальном чуть позже ...
Хочется подвести промежуточный итог и резюмировать все вышесказанное. Итак до выхода 1580 билда МТ5 (текущий билд 1571) что мы имеем.
В индикаторах, в отличии от советников, при смене ТФ в виду того, что "создаётся новая копия индикатора, которая ничего не знает о предыдущей копии", происходит переинициализация всех переменных, кроме того порядок выполнения OnDeinit старого ТФ и OnInit нового ТФ непредсказуем вне зависимости от переключения ТФ "вверх" или "вниз"(практика пока противоречит сказанному ув. Славой) . В связи с этим у программистов возникает ряд проблем и неопределенностей. Например:
- программер, который не читал эту тему при создании индикатора для чего-то в OnInit создает какой-либо объект, логично делая проверку перед его созданием на существование объекта с таким именем. Также, что тоже логично, он прописывает удаление данного объекта в OnDeinit. При смене ТФ если первым выполняется OnInit нового ТФ, происходит проверка на существование объекта, выясняется что он уже существует, и он не создается, т.к. уже создан. После чего выполняется ОnDeinit старого ТФ и объект удаляется. Программист в ступоре. Где мой объект, почему он удалился? Еще в больший ступор он впадет, когда в следующий раз при смене ТФ, когда последовательность выполнения OnInit и OnDeinit будет другая, объект не удалиться. То удаляется, то не удаляется.... После длительных исследований начнется обращение в Сервисдеск, новые темы на форуме о старом.
Это только самая простая ситуация. Будут и другие, т.к. эта особенность не описана в документации и об этом можно прочесть только на форуме.
Если же вам захочется создать что-нибудь эдакое и передавать некоторые параметры из старой копии индикатора новой при смене ТФ, то OnDeinit для этого использовать нельзя ввиду непредсказуемости последовательности выполнения операций инициализации и деинициализации. На мой взгляд самым оптимальным решением в этом случае является применение передачи данных(параметров) через ресурсы с использованием следующих инструментов: ResourceCreate на основе массива пикселей и ResourceReadImage, но это достаточно громоздко и необходимо будет позаботиться о безконфликтности ресурсов, если использовать несколько одинаковых индикаторов в одном окне, а также каждый раз когда меняются данные, которые надо передать для другой копии, необходимо сохранять их в непереинициализируемом ресурсе, т.к. время возможной смены ТФ для программы не известно в виду бесполезности использования OnDeinit. Я это уже давно реализовал (например в этом продукте), поэтому знаю, о чем говорю. Реализация передачи данных через файлы и через глобальные переменные терминала - это менее удачное решение (ИМХО).
Если с выходом нового билда 1580 будет все, как говорил Слава, то это не упростит, задачу, т.к. деинициализация старой копии индикатора будет происходить после инициализации новой копии. Но зато не будет неопределенности.
Стоит надеятся, что все же разработчики обратили внимание на эту проблему, раз пытаются что-то исправить.
Ждем новый билд.
Есть в этом действительно некая проблема , советник прекрасно работает при переключении ТФ , а индикатор в ЭТОЙ ЖЕ ситуации работает совсем иначе.
Никаких проблем, если вы знаете об этой недокуметнированной особенности и имеете дело только с самым простым случаем - с граф. объектами. Я про тех кто не знает данную особенность, думаю эту тему на форуме прочитает очень маленький % программистов и мне просто жаль их времени на выяснение всех нюансов. Я то побывал в этой ситуации, прежде чем разобрался в сути.