Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ок, будем резать.
Цена последней сделки, как зарепортила биржа или торговый/дата шлюз.
Вообще рекомендую запрашивать режим COPY_TICKS_INFO, где будут приходить бид-аск.
Вчера что-то не заострил внимание, используя режим COPY_TICKS_INFO цены бид и аск обязательно будут приходить вместе? Т.е., по сути, это режим для форекса?
Сейчас просто поведение такое же как и в режиме COPY_TICKS_ALL (т.е. может приходить отдельно бид (аск = 0), отдельно аск (бид = 0)) после запроса <5000 (примерно) тиков и обе цены если более.
Также возвращается меньшее количество тиков, чем запрошено (режим COPY_TICKS_INFO, COPY_TICKS_ALL - сколько запросил - столько и вернулось).
Думаю что-то не так...
Вчера что-то не заострил внимание, используя режим COPY_TICKS_INFO цены бид и аск обязательно будут приходить вместе? Т.е., по сути, это режим для форекса?
Можно и не резать :) а сделать отдельную расширенную структуру для CopyTicks.
Отдельной структуры точно не будет.
Поэтому будем расширять новым полем в конце.
Нарежьте, пожалуйста, как-то так:
Эти данные у нас есть.
Пока сильно думаем, имеем ли право расшить структуру MqlTick. Могут пострадать те, кто оперируют размерами этой структуры. В принципе, ради будущего, можно резануть по живому и расширить структуру.
К релизу следующей пятницы примем решение.
Кто использовал MqlTick раньше делал sizeof(MqlTick), а кто такого не делал - для него эта ситуация будет хорошим уроком по правильному программированию.
В общем: "резать к чертовой матери"
Информация об ОИ, текущем количестве ордеров на покупку и продажу и т.д. является специфической для торговой площадки ФОРТС, на других площадках (форекс и биржах) ее нет. Следовательно кажется сомнительным включение этой информации в унифицированный интерфейс MqlTick. А вот насчет полей action и time_count - действительно из наличие было бы полезным.
Да без разницы в какую структуру включат. Можно и в отдельную - чего, видимо, не будет в ближайшие годы.
Начал уже вспоминать старинный протокол ДДЕ - придется, все-таки, на квик завязываться, получать эту инфу оттуда.
Без точного времени time_count (до мс) необходимость тиков вообще сомнительна.
Да без разницы в какую структуру включат. Можно и в отдельную - чего, видимо, не будет в ближайшие годы.
Начал уже вспоминать старинный протокол ДДЕ - придется, все-таки, на квик завязываться, получать эту инфу оттуда.
Без точного времени time_count (до мс) необходимость тиков вообще сомнительна.
Вообще как бы эта инфа в МТ5 есть и давно транслируется. Доступна через функции SymbolInfoGet*. Никто не запрещает в момент получения тика делать запрос по этой информации и объединять ее в своих типах данных.
Другой вопрос, что централизованное серверное хранение, всегда надежнее своего. Не надо задумываться о хранении котировок - все это очень удобно. Но повторюсь, не является критично не невосполнимым.
Без точного времени time_count (до мс) необходимость тиков вообще сомнительна.