Нужна помощь разработчиков MT4 и программистов - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну и флуда развели...
Тоже считаю, что зацикливание советника это моветон. Изменение параметров только после окончания цикла start - вполне логично. Топикстартер не мог не понимать, что проблема в его бесконечном цикле, т.к. он не дилетант. Однако не написал в первом сообщении о бесконечном цикле в советнике ни слова. Я лично таких систем в советниках не делал, но как я понимаю, судя по постам, этого и раньше не было - окно с параметрами в зацикленных советниках просто не открывалось. А значит утверждение ТС "Это приводит к принципиальной несовместимости существующих советников с новыми сборками MT4." не соответствует действительности - в старых сборках МТ4 такие советники тоже не позволяли менять параметры, так как было невозможно открыть окно, пока не завершится цикл.
EventSetMillisecondTimer действительно решает проблему. Но как давно эта функция появилась? Разве раньше не было только EventSetTimer? С минимальным промежутком вызова в 1 секунду такое событие полностью бесполезно при написании систем для реальной торговли, когда тиков по каждому инструменту может приходить десяток за секунду.
В справке по таймерам ссылки на эту функцию до сих пор нет! Обнаружил её только что случайно, в виде подсказки при вводе EventSet.
Есть, однако, на мой взгляд одна проблема и одно несоответствие в новом MQL 4/5: при деинициализации и инициализации не происходит удаления и создания заново динамических объектов в глобальных переменных...
Есть, однако, на мой взгляд, в отношении инициализации переменных, одна проблема и одно несоответствие в новом MQL 4/5: при деинициализации и инициализации не происходит удаления и создания заново динамических объектов в глобальных переменных. То есть, если параметры советника считываются в конструкторах динамически создаваемых объектов в глобальных переменных, и в дальнейшем происходит работа с ними, то при изменении параметров советник будет продолжать работать так, как будто изменения параметров не произошло. На мой взгляд, это не логично и глобальные переменные должны деинициализироваться после деинициализации советника, а потом заново инициализироваться перед инициализацией советника. Решается это в данный момент вынесением инициализации и удаления таких переменных в OnInit и OnDeinit
Да, это реально грабли, особенно учитывая, что в документации (ни здесь, ни здесь) не акцентируется внимание, что загрузка теперь не связана 1 к 1 с событием инициализации. Вот таких слов:
Инициализация глобальных переменных производится однократно сразу после загрузки программы в память клиентского терминала.
явно недостаточно, чтобы обратить внимание разработчика на то, что при последующих сменах параметров будет выполнена деинициализация и инициализация, НО НЕ БУДЕТ соответствующих выгрузки и загрузки.
Да, это реально грабли, особенно учитывая, что в документации (ни здесь, ни здесь) не акцентируется внимание, что загрузка теперь не связана 1 к 1 с событием инициализации. Вот таких слов:
Инициализация глобальных переменных производится однократно сразу после загрузки программы в память клиентского терминала.
явно недостаточно, чтобы обратить внимание разработчика на то, что при последующих сменах параметров будет выполнена деинициализация и инициализация, НО НЕ БУДЕТ соответствующих выгрузки и загрузки.
Да не нужна никакая загрузка/выгрузка и переинициализация переменных. Об инициализации переменных программист обязан заботиться.
Да не нужна никакая загрузка/выгрузка и переинициализация переменных. Об инициализации переменных программист обязан заботиться.
О том то и речь, что не сказано ясно, когда эта самая инициализация производится. Код с глобальной переменной:
int x = 0;
это тоже - инициализация. Но в документации явно не прописано, что это как раз не является инициализацией, с точки зрения МК.
Строго говоря, в МТ сейчас существует 2 разных инициализации: одна выполняется при загрузке программы, а вторая при смене "окружения" в момент вызова OnInit. Плохо, что это приходится раскапывать.пр
При запуске программы - холодный старт. Происходит распределение памяти под переменные и их инициализация начальными значениями.
При работе - тёплый старт. Тут об инициализации переменных обязан заботиться программист и это хорошо.
При запуске программы - холодный старт. Происходит распределение памяти под переменные и их инициализация начальными значениями.
При работе - тёплый старт. Тут об инициализации переменных обязан заботиться программист и это хорошо.
Хорошо или плохо, это вопрос философский... а вот то, что в Документации об этом 0,0 инфы - это не есть гуд...
Причем, если я правильно помню, то раньше такого не было, то есть это, мягко выражаясь, "фича", специально для "удобства" программистов добавленная, но которая нарушает инвариантность существующих кодов (писанных под прежние правила инициализации). Таким образом не соблюдается незыблемый принцип сохранения совместимости старого кода с новыми версиями софта везде, где это возможно.
Никто не против новых фич и оптимизаций. Но почему бы не делать их так, чтобы не ломать старые коды? В частности, для такой новой инициализации вполне можно было выделить дополнительную команду препроцессора по аналогии с #property strict. Сделать например, #property lazyinit, и если она в коде указана программистом (т.е. явно, что означает его осведомленность о новой инициализации в mql), то радуемся оптимизированной оптимизации. А если не указана, то радуемся тому, что прежние коды работают стабильно без всякого перелопачивания и вылавливания мест, где могли остаться глобальные переменные, которые теперь, видите-ли нужно не только продекларировать, но и отдельно проинициализировать в OnInit. Для каждой такой переменной вместо одной строки кода будет 2.