Ошибки, баги, вопросы - страница 492
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Обязательно, именно на всех.
Сколько было доступно, столько и получили. Так и понимать. Проверьте доступную глубину истории. Перед запросом данных необходимо убедиться, что они есть. Какой у Вас билд? недавно правили ошибку с копированием месячных таймфреймов, возможно это она.
Значит плохо проверяли, или советник НЕ мультивалютный, а просто может работать на разных символах. Доводы простые - знание того, что тики приходят на разные символы в разное время. Соответственно, если советник стоит в OnTick EURUSD (например), а проверяет индюк или даже просто тиковые изменения GBPUSD вместо EURUSD, то результат будет разным. В частности, сформированный бар на EURUSD может случиться до формирования бара с тем же временем на GBPUSD. Будете торговать GBPUSD дважды по одному и тому же бару: прежний бар GBPUSD все еще будет считаться новым (нулевым). Про мультивалютные индикаторы вообще все очевидно. Учите матчасть.
какая мат часть млин, тик пришел на 1 паре входим, а если по второй тик запоздал и х...
с ним т.к. нам цена нужна в момент появления нового бара а тики отлавливать
с целью появления нового бара на всех символах роли не сыграет, но здесь же от
стратегии зависит, если вы не скальпер
Хотелось бы еще раз поинтересоваться у команды MQ, планируется ли довести до рабочего состояния функцию iCustom().
В настоящее время авторы экспертов не могут предложить клиентам универсальное решение с использованием iCustom(),
при котором клиент мог бы сам задавать имя, используемого экспертом внешнего индикатора.
Для этого заказчику обязательно нужно иметь исходник эксперта, а также самостоятельно вручную имя каждого индикатора прописывать в код эксперта, что мягко говоря неудобно.
Также существует проблема обязательного явного указания значения содержимого ячеек индикаторного буфера.
Если ячейке индикаторного буфера в тексте индикатора не присвоить явно какое-либо значение (пустое или непустое), то указанные ячейки функция iCustom() в эксперте может заполнять
произвольным мусором. Думаю, что такая работа функции не может считаться корректной.
Хотелось бы еще раз поинтересоваться у команды MQ, планируется ли довести до рабочего состояния функцию iCustom().
В настоящее время авторы экспертов не могут предложить клиентам универсальное решение с использованием iCustom(),
при котором клиент мог бы сам задавать имя, используемого экспертом внешнего индикатора.
Для этого заказчику обязательно нужно иметь исходник эксперта, а также самостоятельно вручную имя каждого индикатора прописывать в код эксперта, что мягко говоря неудобно.
В iCustom можно передавать динамическое имя вызываемого индикатора, но набор параметров у каждого кастомного индикатора свой.
К сожалению, универсального решения вопроса "как не зная что и с какими параметрами будет вызываться, безопасно реализовать вызов, не трогая код?" мы не знаем.
Если я правильно понял, Вы хотите сделать плагинную систему, когда сторонний пользователь указывает в настройках эксперта любое имя индикатора с параметрами (например, "MyIndicator(10,20,50,100)"). Для такого случая с жестким форматом имени Вы можете самостоятельно распарсить строку, сформировать блок параметров и реализовать в виде оберточного класса динамический вызов iCustom с разным набором параметров. То есть, внутри будет скрыто несколько вариантов вызова iCustom с разными наборами/количеством параметров.
Также существует проблема обязательного явного указания значения содержимого ячеек индикаторного буфера.
Если ячейке индикаторного буфера в тексте индикатора не присвоить явно какое-либо значение (пустое или непустое), то указанные ячейки функция iCustom() в эксперте может заполнять
произвольным мусором. Думаю, что такая работа функции не может считаться корректной.
Это уже наглость и откровенная ленивость разработчика не заполнять буфер, которые ему дали в полное распоряжение.
Подсистема исполнения не знает как Вы используете индикаторный буфер и не имеет права заполнять его какими-то либо значениями, особенно в моменты массовых перевыделений (подкачка или апдейты чартов). Индикатор в обязательном порядке уведомляется обо всех случаях необходимости пересчета через функцию OnCalculate(...,const int prev_calculated,...) и параметр prev_calculated.
В iCustom можно передавать динамическое имя вызываемого индикатора, но набор параметров у каждого кастомного индикатора свой.
К сожалению, универсального решения вопроса "как не зная что и с какими параметрами будет вызываться, безопасно реализовать вызов, не трогая код?" мы не знаем.
Если я правильно понял, Вы хотите сделать плагинную систему, когда сторонний пользователь указывает в настройках эксперта любое имя индикатора с параметрами (например, "MyIndicator(10,20,50,100)"). Для такого случая с жестким форматом имени Вы можете самостоятельно распарсить строку, сформировать блок параметров и реализовать в виде оберточного класса динамический вызов iCustom с разным набором параметров. То есть, внутри будет скрыто несколько вариантов вызова iCustom с разными наборами/количеством параметров.
Под проблемной необходимостью внесения изменений в код имелось ввиду требование явно указывать имя индикатора при тестировании
в формате #property tester_indicator "Name.ex5", а не разное количество параметров индикатора.
Индикаторы можно использовать и с параметрами по умолчанию, выбирая лишь номер индикаторного буфера с соответствующим сигналом.
Это уже наглость и откровенная ленивость разработчика не заполнять буфер, которые ему дали в полное распоряжение.
Подсистема исполнения не знает как Вы используете индикаторный буфер и не имеет права заполнять его какими-то либо значениями, особенно в моменты массовых перевыделений (подкачка или апдейты чартов). Индикатор в обязательном порядке уведомляется обо всех случаях необходимости пересчета через функцию OnCalculate(...,const int prev_calculated,...) и параметр prev_calculated.
Неужели сложно в iCustom() неиспользуемым ячейкам присваивать Empty_Value, а не забивать их мусором из стека?
https://www.mql5.com/ru/forum/1111/72233#comment_72233
Заметим, что реальное значение ячеек буфера остается равным Empty. Фальсификацией занимается именно iCustom().
Под проблемной необходимостью внесения изменений в код имелось ввиду требование явно указывать имя индикатора при тестировании
в формате #property tester_indicator "Name.ex5", а не разное количество параметров индикатора.
Вопрос будем дальше решать - там есть свои нюансы.
Неужели сложно в iCustom() неиспользуемым ячейкам присваивать Empty_Value, а не забивать их мусором из стека?
https://www.mql5.com/ru/forum/1111/72233#comment_72233
Этого делать нельзя. Прочтите мой ответ еще раз, пожалуйста.
Причина, почему iCustom() присваивает произвольные значения тем ячейкам буфера, которые в реальности ничем не заполнялись, мне не ясна, как и то, почему этого никак нельзя избежать.
Предполагаю, что это как-то связано с распределением памяти под соответствующий массив данных индикаторного буфера.
Подобная работа iCustom(), когда невозможно определить происхождение и истинность данных, мне кажется недопустимой и создающей дополнительные риски для пользователя.
Если iCustom() и так присваивает ячейкам буфера произвольные, не соответствующие реальным значения,
то почему бы не ему не присваивать этим ячейкам значение, равное Empty_Value, как это реализовано в МТ4.
Тогда по крайней мере был бы понятен их статус.
а так
есть округление все равно пишет, так и надо ?
не спорю
а так
есть округление все равно пишет, так и надо ?