Последовательность выполнение Init() и DeInit() - страница 9
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Спасибо конечно за код. Только с советниками и так все замечательно, т. к. при смене ТФ не происходит переинициализации переменных, тогда как в индикаторах происходит. Если хотите реально помочь советом, "пробежитесь" пожалуйста ещё раз менее торопливо.
Николай, я по теме пробежался, причем еще когда писал первый пост. При этом не нашел обсуждение поведения советника в ситуации смены ТФ , Да - речь в теме идет в основном о индикаторах, хотя автор в своем посте написал "Написан индикатор или советник."
Привел пример , который проверил и он работает - в рамках советника. Что ж Вы - то упрекаете меня то в невнимательности , то отправляете перечитывать тему , то обсуждаете - что разумно или не разумно. Кроме того сами почитайте первую страницу
там вообще не ясно - о советнике или о индикаторе идет речь, в том числе в вашем посте внятно не написано - что речь идет именно о индикаторе.
ПРИМЕР ВАШЕГО ПОСТА :
И что ВСЁ!?
Я экспериментировал и использую этот код причины(REASON_CHARTCHANGE) во всю. А что толку если все переменные снова устаналиваются в первоначальное состояние, а OnDeinit может выполниться после OnInit нового ТФ
Из сказанного разве ясно , что переменные устанавливаются в первоначальное состояние именно в индикаторе ?
А в эксперте это как раз легко реализуется. Человек читающий ВАШ пост может подумать - что и в эксперте происходит такая же ерунда.
----
Ответ на этот вопрос! "при смене ТФ не происходит переинициализации переменных, тогда как в индикаторах происходит."
можно сохранять значения переменных куда нибудь, в глобалы например,...
ИЛИ НА ДИСК В ФАЙЛ а после ПЕРЕЗАПУСКА ИНДИКАТОРА , в OnInit прочитать и восстановить.
------------
Если вы увлечены только проблемой смены ТФ именно для индикатора - это не означает, что другим, в том числе и мне , не интересен вариант смены ТФ для советника.
Помочь советом , именно с индикатором , увы не могу, т.к. не знаю как это реализовать на практике, но буду с интересом наблюдать за предложенными решениями.
Как минимум я понял , разработчики читают эту тему, и даже в билде 1580 кое что поправили. Возможно они и предложат решение.
Вы не читали разве то, что я написал несколько раз?
В индикаторах - никак. В пятёрке с самого начала было никак. Так как загружается совсем новая копия индикатора со всеми вытекающими последствиями
Спасибо что честно ответили.
В пятёрке всегда было никак. Может уже пора исправить?
Неужели так трудно сделать правильный порядок? Экономия времени на старте затем выливается в бесконечных проверках на каждом тике.
Я уже привык к парадигме ООП в МТ5 и знаю где находятся грабли и как приделать костыли для обхода этих граблей, если конечно новых граблей не подложат. Получается легче удалить объект и создать новый, чем изменить пару параметров.
По аналоги, в автомобиле вместо того чтобы заменить масло и ехать дальше, лучше выкинуть автомобиль и сделать новый.
Напоминает мультик:
Подскажите пожалуйста
Я решил написать программу, которая
1. на Ините выводит 8 строк
2. на ДеИните выводит еще 8 строк
Запустил в тестере (2 дня прогнал и получил)
Почему то он выборочно не выводит в журнал некоторые строки
Это так же для ускорения???
------------------------------------------------------------------------------------------
ВОПРОС СНЯТ ТАК КАК В ПОЛНЫХ ЛОГАХ ВСЯ ИНФОРМАЦИЯ ЕСТЬ
------------------------------------------------------------------------------------------
В документацию необходимо добавить
1. В журнале отображается не вся информация на которую рассчитывает программер
-------- ОБЯЗАТЕЛЬНО НАДО СМОТРЕТЬ ПОЛНЫЙ ЛОГ !!!
Хочется подвести промежуточный итог и резюмировать все вышесказанное. Итак до выхода 1580 билда МТ5 (текущий билд 1571) что мы имеем.
В индикаторах, в отличии от советников, при смене ТФ в виду того, что "создаётся новая копия индикатора, которая ничего не знает о предыдущей копии", происходит переинициализация всех переменных, кроме того порядок выполнения OnDeinit старого ТФ и OnInit нового ТФ непредсказуем вне зависимости от переключения ТФ "вверх" или "вниз"(практика пока противоречит сказанному ув. Славой) . В связи с этим у программистов возникает ряд проблем и неопределенностей. Например:
- программер, который не читал эту тему при создании индикатора для чего-то в OnInit создает какой-либо объект, логично делая проверку перед его созданием на существование объекта с таким именем. Также, что тоже логично, он прописывает удаление данного объекта в OnDeinit. При смене ТФ если первым выполняется OnInit нового ТФ, происходит проверка на существование объекта, выясняется что он уже существует, и он не создается, т.к. уже создан. После чего выполняется ОnDeinit старого ТФ и объект удаляется. Программист в ступоре. Где мой объект, почему он удалился? Еще в больший ступор он впадет, когда в следующий раз при смене ТФ, когда последовательность выполнения OnInit и OnDeinit будет другая, объект не удалиться. То удаляется, то не удаляется.... После длительных исследований начнется обращение в Сервисдеск, новые темы на форуме о старом.
Это только самая простая ситуация. Будут и другие, т.к. эта особенность не описана в документации и об этом можно прочесть только на форуме.
Если же вам захочется создать что-нибудь эдакое и передавать некоторые параметры из старой копии индикатора новой при смене ТФ, то OnDeinit для этого использовать нельзя ввиду непредсказуемости последовательности выполнения операций инициализации и деинициализации. На мой взгляд самым оптимальным решением в этом случае является применение передачи данных(параметров) через ресурсы с использованием следующих инструментов: ResourceCreate на основе массива пикселей и ResourceReadImage, но это достаточно громоздко и необходимо будет позаботиться о безконфликтности ресурсов, если использовать несколько одинаковых индикаторов в одном окне, а также каждый раз когда меняются данные, которые надо передать для другой копии, необходимо сохранять их в непереинициализируемом ресурсе, т.к. время возможной смены ТФ для программы не известно в виду бесполезности использования OnDeinit. Я это уже давно реализовал (например в этом продукте), поэтому знаю, о чем говорю. Реализация передачи данных через файлы и через глобальные переменные терминала - это менее удачное решение (ИМХО).
Если с выходом нового билда 1580 будет все, как говорил Слава, то это не упростит, задачу, т.к. деинициализация старой копии индикатора будет происходить после инициализации новой копии. Но зато не будет неопределенности.
Стоит надеятся, что все же разработчики обратили внимание на эту проблему, раз пытаются что-то исправить.
Ждем новый билд.
Все граф объекты обзываем с привязкой к текущему ТФ. При инициализации создаём, при деинициализации удаляем. Во время работы индикатора модифицируем по необходимости.
Тут есть проблемы? Нет проблем. Всё чинно от момента запуска индикатора до момента его выгрузки.
Преключаем ТФ. Не важно в какую сторону, вверх или вниз. Запустилась копия индикатора. Это равносильно тому, что индикатор запущен впервые на этом ТФ.
Тут есть проблемы? Нет проблем. Старая копия позаботится об удалении своих объектов, а новая копия создаст свои новые обзывая их согласно текущему ТФ.
Что я делаю не так? Почему я не вижу проблем?
Все граф объекты обзываем с привязкой к текущему ТФ. При инициализации создаём, при деинициализации удаляем. Во время работы индикатора модифицируем по необходимости.
Тут есть проблемы? Нет проблем. Всё чинно от момента запуска индикатора до момента его выгрузки.
Преключаем ТФ. Не важно в какую сторону, вверх или вниз. Запустилась копия индикатора. Это равносильно тому, что индикатор запущен впервые на этом ТФ.
Тут есть проблемы? Нет проблем. Старая копия позаботится об удалении своих объектов, а новая копия создаст свои новые обзывая их согласно текущему ТФ.
Что я делаю не так? Почему я не вижу проблем?
Никаких проблем, если вы знаете об этой недокуметнированной особенности и имеете дело только с самым простым случаем - с граф. объектами. Я про тех кто не знает данную особенность, думаю эту тему на форуме прочитает очень маленький % программистов и мне просто жаль их времени на выяснение всех нюансов. Я то побывал в этой ситуации, прежде чем разобрался в сути.
я никогда слыхом не слыхивал о нюансах таких как нюансы описываемые в этой ветке, однако ни разу не встречался с проблемами о которых здесь толкуют.
если хотите передавать что то в другую копию индикатора, то не нужно этого в делать деините - держите актуальными передаваемые данные на протяжении всей работы индикатора например в гл. переменных терминала, тогда независимо от причины выгрузки индикатора (смена ТФ, мама выдернула вилку из розетки "что б не фонило когда все спят", землетрясение, смена магнитных полюсов земли и т.д.) следующий запуск индикатора (в том числе и копия при смене ТФ) получит из этого волшебного источника данных всю необходимую информацию (на невезучие случаи глобального масштаба можно держать данные на облачном диске).
Ребята, ну нет проблем ведь никаких.
Все граф объекты обзываем с привязкой к текущему ТФ. При инициализации создаём, при деинициализации удаляем. Во время работы индикатора модифицируем по необходимости.
Тут есть проблемы? Нет проблем. Всё чинно от момента запуска индикатора до момента его выгрузки.
Преключаем ТФ. Не важно в какую сторону, вверх или вниз. Запустилась копия индикатора. Это равносильно тому, что индикатор запущен впервые на этом ТФ.
Тут есть проблемы? Нет проблем.
Есть проблема: одновременное существование объектов от разных индикаторов. "Извините, у нас временные технические неполадки" (но через несколько секунд они будут устранены, когда произойдет DeInit старого индикатора)
Старая копия позаботится об удалении своих объектов, а новая копия создаст свои новые обзывая их согласно текущему ТФ.
Что я делаю не так? Почему я не вижу проблем?
Узкий круг зрения. Вот и не видно. Немного расширьте кругозор. Первые проблемы возникают уже при работе с файлами, т. к. непонятно, успел предыдущий индикатор сбросить в файл данные или еще нет. Придется придумывать какие-то флаги в глобальных переменных терминала. То есть делать свою синхронизацию (новая копия индикатора должна будет ждать, когда же старая копия сбросит накопленные данные). Кстати, здесь проблема еще в том, что такая синхронизация возможна только в OnCalculate(). А что делать, если переключение произошло в выходные? Новая копия не запустится до понедельника? А, ну да, можно ведь на таймер посадить! Куда ж мы без него при работе с файлами (Слышал я, что по воробьям можно отлично из пушки лупить; рогатка нервно курит в сторонке)?
Это еще простые проблемы. Попробуйте такую логику учесть при работе с многопоточной DLL. Вот там веселье намечается... Ну ничего, сильнее будем )))
я никогда слыхом не слыхивал о нюансах таких как нюансы описываемые в этой ветке, однако ни разу не встречался с проблемами о которых здесь толкуют.
если хотите передавать что то в другую копию индикатора, то не нужно этого в делать деините - держите актуальными передаваемые данные на протяжении всей работы индикатора например в гл. переменных терминала, тогда независимо от причины выгрузки индикатора (смена ТФ, мама выдернула вилку из розетки "что б не фонило когда все спят", землетрясение, смена магнитных полюсов земли и т.д.) следующий запуск индикатора (в том числе и копия при смене ТФ) получит из этого волшебного источника данных всю необходимую информацию (на невезучие случаи глобального масштаба можно держать данные на облачном диске).
Ребята, ну нет проблем ведь никаких.
Есть проблема: одновременное существование объектов от разных индикаторов. "Извините, у нас временные технические неполадки" (но через несколько секунд они будут устранены, когда произойдет DeInit старого индикатора)
Узкий круг зрения. Вот и не видно. Немного расширьте кругозор. Первые проблемы возникают уже при работе с файлами, т. к. непонятно, успел предыдущий индикатор сбросить в файл данные или еще нет. Придется придумывать какие-то флаги в глобальных переменных терминала. То есть делать свою синхронизацию (новая копия индикатора должна будет ждать, когда же старая копия сбросит накопленные данные). Кстати, здесь проблема еще в том, что такая синхронизация возможна только в OnCalculate(). А что делать, если переключение произошло в выходные? Новая копия не запустится до понедельника? А, ну да, можно ведь на таймер посадить! Куда ж мы без него при работе с файлами (Слышал я, что по воробьям можно отлично из пушки лупить; рогатка нервно курит в сторонке)?
Это еще простые проблемы. Попробуйте такую логику учесть при работе с многопоточной DLL. Вот там веселье намечается... Ну ничего, сильнее будем )))
Я же четко написал - держите необходимые для передачи в копию данные всегда актуальными, не нужно это делать только при ините, всегда держите актуальными.
Все остальные случаи надуманы из за криворукости.
Если проблема с одновременным запуском одного и того же индикатора, то создавайте каждый раз уникальные объекты с привязкой к ТФ и если уже есть объекты прибавляйте к названию 1.
Никто не привел ни одного конкретного случая, где проблемы не преодолимы в связи с текущим порядком работы терминала с индикаторами. И проблемы эти из за неправильной работы с индикаторами.
Вообще, многие, как я погляжу, не понимают, что не спроста существуют 3 типа программ (скоро будет 4-й).