Ошибки, баги, вопросы - страница 2021
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Воспроизведение бага
Результат такой
Повторный запуск
Т.е. SYMBOL_TRADE_TICK_VALUE возвращает нули при первом запуске, если не делать Sleep();
ЗЫ На тему невидимого символа в Обзоре рынка. Если до шага запуска скрипта попытаться открыть чарт USDJPY (нажать Enter и ввести "USDJPY"), то ничего не получится. А если после запуска скрипта - получится. Хотя Обзор рынка не изменился.
Воспроизведение бага
Результат такой
Повторный запуск
Т.е. SYMBOL_TRADE_TICK_VALUE возвращает нули при первом запуске, если не делать Sleep();
ЗЫ На тему невидимого символа в Обзоре рынка. Если до шага запуска скрипта попытаться открыть чарт USDJPY (нажать Enter и ввести "USDJPY"), то ничего не получится. А если после запуска скрипта - получится. Хотя Обзор рынка не изменился.
Добавьте в начало скрипта такой цикл
И посмотрите сколько символов будет распечатано.
При первом запуске обращение к AUDJPY только добавляет в обзор рынка AUDUSD и USDJPY и только при втором обращении через эти пары получает свойство символа. Именно это и вызывает проблему с OrderCalcMargin в моём случае.
Много раз об этом писали. Не правят почему-то.
Всем здрасте!
Помогите, пожалуйста, начинающему.
Исполнена функция на поиск ценового максимума. Как возможно вычислить и вернуть в код НОМЕР БАРА с определенным ценовым максимумом?
Добавьте в начало скрипта такой цикл
И посмотрите сколько символов будет распечатано.
При первом запуске обращение к AUDJPY только добавляет в обзор рынка AUDUSD и USDJPY и только при втором обращении через эти пары получает свойство символа. Именно это и вызывает проблему с OrderCalcMargin в моём случае.
Думаю, порешают, как с этим
Получил ответ в сервисдеске. Исправят.
Спасибо.
По поводу бага "вокруг" OrderCalcMargin() оформил Заявку в СД
Трудно быть уверенным, когда в справке MQL4/5 прямое противоречие:
...Необходимо помнить, что параметры передаются в функцию задом наперед, то есть сначала вычисляется и передается самый последний параметр, затем предпоследний и так далее. Последним по очереди вычисляется и передается параметр, стоящий первым после открывающей скобки.
...Обратите внимание, что порядок выполнения выражений x1,..., xn гарантируется.
В чём же противоречие? Задом наперёд - и всё. Обратного утверждения нет.
- Эти две рекомендации находятся в отдельных разделах справки.
Когда Вы читаете в разделе
"Вызов функции с аргументами x1, x2,..., xn"
порядок выполнения выражений x1,....,xn гарантируется, то о каком порядке Вы думаете?
о порядке x1,...,xn или о порядке xn,....,x1 ?
- Эти две рекомендации находятся в отдельных разделах справки.
Когда Вы читаете в разделе
"Вызов функции с аргументами x1, x2,..., xn"
порядок выполнения выражений x1,....,xn гарантируется, то о каком порядке Вы думаете?
о порядке x1,...,xn или о порядке xn,....,x1 ?
Да, вы правы, это сбивает с толку.
Впрочем, я считаю, что в любом случае закладывать логику своего алгоритма на конкретный порядок передачи аргументов - это плохая практика. Тем более когда эти вычисления справа-налево, это запутывает понимание кода. Поэтому если и применять это, то лишь в каких-то некритичных местах, типа вывода на печать.
Порядок расчета выражений в Print() справа налево. Вроде как... Пока... Тоже проверял предварительно :)
Справочник MQL5\Основы языка\Операции и выражения\Другие операции
Вызов функции с аргументами x1, x2,..., xn
Обратите внимание, что порядок выполнения выражений x1,..., xn гарантируется.
Это лишний раз свидетельствует о пользе ключевого слова С++ inline (здесь было мнение что оно якобы устаревшее).
Помимо прочего inline фактически означает отказ программиста от использования порядка вычисления параметров функции и если компилятор решит сделать inline функцию встраиваемой, то компилятор может использовать прямой порядок вычисления как более эффективный (обратный порядок вычисления очевидно эффективен только для вызываемых функций).
В то же время если компилятор решит сделать встраиваемой не inline функцию то он должен использовать (общий) обратный порядок вычисления даже если это ведет к потере эффективности (потому что программист заложился на это порядок не объявив функцию inline)
inline был бы к месту и в MQL, где порядком вычисления нельзя управлять явно