Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Судя по запросам тикового индикатора, данные поля time_msk кратны 1000. т.е. ни о каких миллисекундах речи не идёт, разрешение осталось 1 секунда.
Вопрос: какой тогда был смысл в расширении структуры MqlTick?
У Вас не так?
У меня есть Демо на Опенброкер и реал счет там же. На реале все Access сервера дают одинаковый результат. ну и на демо тоже самое. Смотрел на Si-6.16, RTS-6.16, SBRF-6.16. Все изменения кратны 1000.
У Вас не так?
Сейчас действительно по запросу SymbolInfoTick в возвращаемой структуре MqlTick отдаются нули вместо реальных миллисекунд (кратно 1000)
Подождите, пожалуйста, следующий билд.
PS по запросу CopyTicks миллисекунды отдаются как есть
Этот индикатор я скачал с данной ветки для теста. Он получает 30 последних тиков именно через CopyTicks. Как вариант, возможно мне следует пробовать на другом сервере (не опенброкер).
>>"отдаются нули вместо реальных миллисекунд"
Отдаются не нули, но всегда одинаковые числа с разностью кратной 1000. (...2064, ...2064, ...3064, ..., ..., ..4064 )
Этот индикатор я скачал с данной ветки для теста. Он получает 30 последних тиков именно через CopyTicks. Как вариант, возможно мне следует пробовать на другом сервере (не опенброкер).
>>"отдаются нули вместо реальных миллисекунд"
Отдаются не нули, но всегда одинаковые числа с разностью кратной 1000. (...2064, ...2064, ...3064, ..., ..., ..4064 )
Нули отдаются функцией SymbolInfoTick.
В CopyTicks отдаются реальные миллисекунды. Если это 2064, 3064, 4064, то значит так и было. Почему так было, я не знаю
Посмотрел Ваш код. Что за спецификатор вывода %-4d? time_msc - это long поэтому просто d не идёт. Должно быть %I64d
Нули отдаются функцией SymbolInfoTick.
В CopyTicks отдаются реальные миллисекунды. Если это 2064, 3064, 4064, то значит так и было. Почему так было, я не знаю
Посмотрел Ваш код. Что за спецификатор вывода %-4d? time_msc - это long поэтому просто d не идёт. Должно быть %I64d
Да, извините. Код не мой. У автора действительно косяк в StringFormat. Вывел в каждой итерации цикла через Print (tick.time_msc) . Результат все нули в конце, в итоге миллисекунд всё таки нет. Запрос CopyTicks идёт постоянно.
Нули отдаются функцией SymbolInfoTick.
В CopyTicks отдаются реальные миллисекунды. Если это 2064, 3064, 4064, то значит так и было. Почему так было, я не знаю
Посмотрел Ваш код. Что за спецификатор вывода %-4d? time_msc - это long поэтому просто d не идёт. Должно быть %I64d
Изменил индикатор из первого поста - нечего баловаться со всякими StringFormat, теперь будет так:
Да, извините. Код не мой. У автора действительно косяк в StringFormat. Вывел в каждой итерации цикла через Print (tick.time_msc) . Результат все нули в конце, в итоге миллисекунд всё таки нет. Запрос CopyTicks идёт постоянно.
Вот Ваш индикатор на данных MetaQuotes Demo
Задайте вопрос Вашему брокеру про отсутствие миллисекунд в тиках
Вот Ваш индикатор на данных MetaQuotes Demo
Задайте вопрос Вашему брокеру про отсутствие миллисекунд в тиках
ps мой билд клиента 1340
juriy5555:
Пока не знаю, что и у кому конкретно писать, я в этом несколько месяцев. Буду надеяться, что ОпенБрокер всё таки обновит сервер.
ps мой билд клиента 1340
Вот у меня тоже вопрос, правда немного другого плана и мне тоже интересно, корректна ли информация, передаваемая из тиков.
Вопрос по реальным объемам.
Если запрашивать информацию по тикам из индикатора, то туда попадает реальный объем в массив volume[]. И, по идее, если получать информацию из тиков, то объем, накопленный за свечу, должен совпадать со значением из массива volume[].
Привожу пример тестового кода:
Пока не будем привязываться к флагам, и предположим, что каждый полученный тик меняет суммарный объем sVol (хотя, насколько я знаю, это не так).
Дожидаемся формирования новой свечи и смотрим, записи в журнале. Брокер Открытие, реальный счет, билд 1340, RTS-6.16:
И т.д., реальный объем из индикатора будет гораздо больше, чем накопленный. В связи с чем возникает несколько вопросов к разработчикам:
1. Должен ли совпадать объем, получаемый из массива volume[] функции OnCalculate() с накопленным объемом, полученным из тиков? Мое мнение, конечно, должен, иначе зачем указывать его в тиках?
2. Корректно ли для накопления объема использовать функцию OnCalculate() или лучше получать объем через OnBookEvent()? В справке написано:
Событие Calculate генерируется только для индикаторов сразу после посылки события Init и при любом изменении ценовых данных. Обрабатывается функцией OnCalculate.
так что, по идее, корректно, но хотелось бы услышать комментарий по этому поводу.
3. Результаты теста приведены БЕЗ анализа флагов. Если анализировать флаги, то, насколько я понимаю, нужно брать объемы из тиков с флагами 24 (одновременное изменение ласта и объема):
Но в таком случае накопленный объем будет еще меньше. Хотелось бы услышать комментарии разработчиков о том, как сейчас правильно анализировать тики (раз записываются все поля) и правильно ли реализованы флаги? Вопрос по правильности реализации возник потому, что не заметил тиков с флагами:
Файл индикатора также в приложении.