Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если ордер исполнился частично, то его не будет в Истории до тех пор, пока он не исполнится полностью (но здесь делать FILLED-проверку делать бессмыленно), либо будет отменен (но здесь и STATE станет Cancelled, т.е. опять же FILLED-проверка не актуальна).
Что-то не работает вообще это всё. Например, имеется несколько ордеров и позиций в рынке, как рынояные так и отложенные buyStop и sellStop. Срабатывает sellStop. В этот момент я хочу открыть противовес. Код такой:
Хотя, срабатывает sellStop, но я попадаю в условие типа сработал buyStop. Это как вообще такое может быть? У меня при тесте нет рыночной позиции buy. Но в журнале вижу:
Как мне тогда сделать так, что бы если ордер перешёл в состояние позиции.. выполнить какое-то действие?
Что-то не работает вообще это всё. Например, имеется несколько ордеров и позиций в рынке, как рынояные так и отложенные buyStop и sellStop. Срабатывает sellStop. В этот момент я хочу открыть противовес. Код такой:
Хотя, срабатывает sellStop, но я попадаю в условие типа сработал buyStop. Это как вообще такое может быть? У меня при тесте нет рыночной позиции buy. Но в журнале вижу:
Как мне тогда сделать так, что бы если ордер перешёл в состояние позиции.. выполнить какое-то действие?
Пример: EES Hedger.
Ловим транзакцию TRADE_TRANSACTION_DEAL_ADD, если сделка по текущему символу и magic равен Original_EA_Magic (если задать его в ноль, то будут отлавливаться только сделки произошедшие от ручной установки отложенных ордеров или от ручной отсылки торговых приказов по-рынку), если тип сделки DEAL_ENTRY_IN (вход в рынок) то открываемся в противоположную сторону.
Пример: EES Hedger.
Ловим транзакцию TRADE_TRANSACTION_DEAL_ADD, если сделка по текущему символу и magic равен Original_EA_Magic (если задать его в ноль, то будут отлавливаться только сделки произошедшие от ручной установки отложенных ордеров или от ручной отсылки торговых приказов по-рынку), если тип сделки DEAL_ENTRY_IN (вход в рынок) то открываемся в противоположную сторону.
Здесь есть стрёмный момент, на первый взгляд:
Блок, где происходит инициализация дефолтными значениями свойств сделки.. Зачем? Нам же нужно получить значения совершённой транзакции.. Они придут какие и есть, на самом деле. К чему нам их обнуление. Ведь значения этих свойств зависят от сервера.. т.е. как он их отработает и вернёт терминалу.
Здесь есть стрёмный момент, на первый взгляд:
Блок, где происходит инициализация дефолтными значениями свойств сделки.. Зачем? Нам же нужно получить значения совершённой транзакции.. Они придут какие и есть, на самом деле. К чему нам их обнуление. Ведь значения этих свойств зависят от сервера.. т.е. как он их отработает и вернёт терминалу.
Это привычка: всегда всё инициализировать. И только потом уже работать. Те кто работает надеясь на авось и не инициализируют - потом часто попадают на трудно вылавливаемые ошибки.
Для примера: Структура торговой транзакции - обратите внимание, что каждый вид транзакции заполняет только НЕКОТОРЫЕ поля, в остальных может быть что угодно.
Что-то не работает вообще это всё. Например, имеется несколько ордеров и позиций в рынке, как рынояные так и отложенные buyStop и sellStop. Срабатывает sellStop. В этот момент я хочу открыть противовес. Код такой:
Хотя, срабатывает sellStop, но я попадаю в условие типа сработал buyStop. Это как вообще такое может быть? У меня при тесте нет рыночной позиции buy. Но в журнале вижу:
Как мне тогда сделать так, что бы если ордер перешёл в состояние позиции.. выполнить какое-то действие?
Здесь есть код на эту тему.
Это привычка: всегда всё инициализировать. И только потом уже работать. Те кто работает надеясь на авось и не инициализируют - потом часто попадают на трудно вылавливаемые ошибки.
Для примера: Структура торговой транзакции - обратите внимание, что каждый вид транзакции заполняет только НЕКОТОРЫЕ поля, в остальных может быть что угодно.
Да. Но это нужно проверять на реале. Потому что никаких данных нет в справке. Там вообще как-то всё убого. Многие вещи сам проверяю. Просто, если понятие ордера и позиции у меня уже пару лет как сложилось, то со сделками только вот пару дней назад как столкнулся. Потому что раньше не нужно было.
Я обычно тоже всё инициализирую, но это локальные вещи, а когда приходят данные из вне, здесь вопрос.. Нужно на реале будет прогнать и поглядеть. Я сторонник минимализма. Если столкнулся с чем-то, тогда включаю в код. А так можно было бы весь спектр ошибок обрабатывать, например. Но это заколебёшся проверять всё. Я об этом тоже думал. Пришёл к выводу, что нужно самые очевидные моменты анализировать. На данный момент, всё и так чётко, кроме кк вот этот аспект со сделками ещё разрулить. Уже работает, но хочу всё это хозяйство запаковать в библиотеку и разгруппировать. Потому что такие пачки кода повторяющиеся это не есть желаемый вариант. Да и у меня в прошлом варианте, всё было правильно, кроме как я выбирал не сделку, а ордер:
Только вот всё-равно, здесь ещё 1 косяк есть очевидный. В наших обоих вариантах есть недочёт. Если ордер не открылся, то он пропариться и больше не откроется. Здесь придётся флаг заводить, на вскидку. А так всё остальное верно.
Viktar Dzemikhau
Вы всё очень усложняете.
Всё очень просто
1. Ордер
Если Вы отправили ордер, то
а) Ордер исполнился полностью
б) Ордер исполнился частично
в) Ордер отклонен
г) Ордер поставлен в очередь
2. Позиция
а) Есть позиция
б) Нет позиции
Коль скоро ордер первичен в торговле, то после оправки ордера
необходимо знать, что с ним произошло (OnTradeTransaction()) в помощь
Если ордер исполнялся, то PositionSelect(symbol) даст всю необходимую инфориацию о позиции.
Вот функция, которая даст всю необходимую инфу об ордере.
prostotrader, да я и не спорю даже. У меня такое иногда бывает. Всегда продумываю всё наперёд. Это не просто. Привычка к оптимизации кода.
А Вашу инфу ещё нужно переварить для начала. Но вижу, что enum'ы можно было взять дефолтные, по идее. А так логика в общем ясно. Хотя, параметр get_data не особо я ещё понял для чего.prostotrader, да я и не спорю даже. У меня такое иногда бывает. Всегда продумываю всё наперёд. Это не просто. Привычка к оптимизации кода.
А Вашу инфу ещё нужно переварить для начала. Но вижу, что enum'ы можно было взять дефолтные, по идее. А так логика в общем ясно. Хотя, параметр get_data не особо я ещё понял для чего.get_data == true - даёт возможность получить абсолютно всю информацию об ордере.
Если get_data == false, то только состояние ордера и его наличие.
Добавлено
В том - то и дело, что дефолтные enum'ы не дают полной картины состояния ордера, в тот момент, когда приходит сообщение в OnTradeTransaction()
Посмотрите, как получаются ORDER_NONE_PARTIAL_CANCELED и ORDER_NONE_PARTIAL, предварительно прочитав комментарий к enum'у
Не так всё просто, как кажется на первый взгляд.