Неизбежная 4108 - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
после OrderSelect нужно обязательно делать проверку
ни разу не встречал такую ошибку ни на реале, ни на демо. Про тестер я вообще молчу - идеальнее торговли не бывает ).
Это действительно редкий случай. Но опять же, все зависит от алгоритма.
Чаще всего приходится делать трал на расстоянии заметно большем, чем позволяет StopLevel,
и в результате вероятность такой 4108 близка к нулю.
Но если тралить максимально плотно - 4108 вылазит даже в тестере, представьте себе.
после OrderSelect нужно обязательно делать проверку
Тоже хорошая идея.
Но я уже писал: в клиентском терминале абсолютно все данные старше, чем на сервере на время пинга,
и OrderCloseTime() в том числе.
Это действительно редкий случай. Но опять же, все зависит от алгоритма.
Чаще всего приходится делать трал на расстоянии заметно большем, чем позволяет StopLevel,
и в результате вероятность такой 4108 близка к нулю.
Но если тралить максимально плотно - 4108 вылазит даже в тестере, представьте себе.
для трала скорее всего вместо стоплевел нужно учитывать уровень заморозки, так называемую фрезу...
Видимо, я неточно выразился. Я имел ввиду подтяжку sl для рыночного, а не изменение цены для отложенного.
Видимо не совсем вникли в мой пост. Перечитайте внимательно.
А. Ну да. Но суть дела не меняется.
На практике я пользуюсь (Ask-Bid) плюс или минус еще какая-то дополнительная дистанция.
Если в результате получается достаточно далеко - тогда и 4108 не бывает.
А если максимально близко, то 130 все же нет, а 4108 иногда проскакивает.
А. Ну да. Но суть дела не меняется.
На практике я пользуюсь (Ask-Bid) плюс или минус еще какая-то дополнительная дистанция.
Если в результате получается достаточно далеко - тогда и 4108 не бывает.
А если максимально близко, то 130 все же нет, а 4108 иногда проскакивает.
4108: "Неверный номер тикета."
Не понял ???
Может быть ошибка совсем не в этом, а в том что с тикетом что то не то, всё-таки
Либо ордер не выбран, либо сначала закрыт(роботом, по стопу, тейку)/удален и следом его модифицировать/закрывать пробуете?
В таком случае - да, будет такая ошибка, хоть и редко
4108: "Неверный номер тикета."
Не понял ???
Может быть ошибка совсем не в этом, а в том что с тикетом что то не то, всё-таки
Ошибка именно в том, что в момент, когда на сервер приходит OrderModify(), данный тикет
оказывается уже закрыт по sl, сервер справедливо возвращает 4108.
То есть, перед тем, как сделать OrderModify(), я делаю проверку, существует ли данный тикет
среди открытых ордеров. Но любой способ проверки оперирует данными, устаревшими
на время пинга. OrderModify() тоже идет на сервер не мгновенно.
Конечно, если sl достаточно далеко, то почти невероятно, чтобы он успел сработать.
А если близко - есть такой риск: внутри терминала тикет числится открытым, но на сервере
уже закрыт.
Ошибка именно в том, что в момент, когда на сервер приходит OrderModify(), данный тикет
оказывается уже закрыт по sl, сервер справедливо возвращает 4108.
То есть, перед тем, как сделать OrderModify(), я делаю проверку, существует ли данный тикет
среди открытых ордеров. Но любой способ проверки оперирует данными, устаревшими
на время пинга. OrderModify() тоже идет на сервер не мгновенно.
Конечно, если sl достаточно далеко, то почти невероятно, чтобы он успел сработать.
А если близко - есть такой риск: внутри терминала тикет числится открытым, но на сервере
уже закрыт.
после OrderSelect нужно обязательно делать проверку
Если ордер выбирается из списка открытых по индексу, у него никогда не будет OrderCloseTime() > 0 именно по той причине, что он ещё в списке открытых, действующих.
Эта проверка обязательна если ордер выбирать по тикету из переменной или массива.