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