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