Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вообще-то, под мейджик отдано целых 8 байт информации, которую можно интерпретировать как угодно. Хоть datetime, хоть double, хоть 4 short, хоть 8 char, хоть 64 бита побитно.
В четвёрке 4 байта мейджика хватало для кодирования чего угодно, а теперь целых 8. Было бы желание.
А это понятно, я и в четверке неплохо этим пользовался, и статью читал (идея очень понравилась).
Вот непонятно просто - Почему в разные местах указаны разные типы?
Подскажите пожалуйста как можно закрыть позицию с установленными ТП и СЛ если цена находится скажем недалеко от ТП, а выйти нужно сейчас.
Я посылаю ордер на открытие новой позиции равной по объему. В большинстве случаев это срабатывает. Но бывают ситуации когда сделка успевает закрыться по ТП и вместо закрытия я получаю новую позицию в рынке... :(
Каким образом мне можно указать, что открываемая позиция относится к закрытию существующей и если основоная поза уже закрыта то новую не открывать?
На ум приходят варианты типа "убрать СЛ и ТП перед закрытием или ждать пока не исполнится ТП" но эти решения некрасивые. Неужели нельзя провести такую простую операцию как ЗАКРЫТИЕ позиции как это было в МТ4 ???
посмотрите PositionClose в классе CTrade.
Уверен, что там будет так же как делаете вы. Вывод напрашивается один - по другому сейчас нельзя.
Но я поддерживаю вашу просьбу. И прошу разработчиков рассмотреть этот вариант.
Добавить тип операции TRADE_ACTION_CLOSE - закрытие позиции по указанному инструменту в своём объёме по текущей цене.
Вообще-то, под мейджик отдано целых 8 байт информации, которую можно интерпретировать как угодно. Хоть datetime, хоть double, хоть 4 short, хоть 8 char, хоть 64 бита побитно.
В четвёрке 4 байта мейджика хватало для кодирования чего угодно, а теперь целых 8. Было бы желание.
Про 8 байт у long и ulong было понятно из Справочника. Настораживает непоследовательность использования этих типов применительно к magic.
Простой пример: при отправке торгового запроса допустимо присвоить request.magic=ULONG_MAX-1. Почему же тогда в Справочнике указано, что функция OrderGetInteger(ORDER_MAGIC) возвращает только тип long? Более того, и для позиций, и для сделок тоже возвращается magic типа long.
Так как же всё задумано изначально? Может, следует для struct MqlTradeRequest указать, что magic относится к типу long, поскольку функции HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() и т.д. не предназначены возвращать целочисленные значения, большие, чем LONG_MAX?
Про 8 байт у long и ulong было понятно из Справочника. Настораживает непоследовательность использования этих типов применительно к magic.
Простой пример: при отправке торгового запроса допустимо присвоить request.magic=ULONG_MAX-1. Почему же тогда в Справочнике указано, что функция OrderGetInteger(ORDER_MAGIC) возвращает только тип long? Более того, и для позиций, и для сделок тоже возвращается magic типа long.
Так как же всё задумано изначально? Может, следует для struct MqlTradeRequest указать, что magic относится к типу long, поскольку функции HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() и т.д. не предназначены возвращать целочисленные значения, большие, чем LONG_MAX?
В действительности магик имеет тип long (это легко проверяется формированием отрицательного магика и магика со значением выходящим за диапазон значений типа long).
Для проверки можно немного модифицировать советник Night (он не использует классы стандартной библиотеки).
Для чистоты эксперимента следует изменить тип параметра EA_Magic на long и сделать распринтовку магика последней сделки в истории (при удачной установке ордера).
Interesting:
В действительности магик имеет тип long (это легко проверяется формированием отрицательного магика и магика со значением выходящим за диапазон значений типа long).
Если так, то необходимо внести уточнение в описание элемента magic структуры MqlTradeRequest, убрав букву "u" из имени типа.
Вообще-то, под мейджик отдано целых 8 байт информации, которую можно интерпретировать как угодно. Хоть datetime, хоть double, хоть 4 short, хоть 8 char, хоть 64 бита побитно.
В четвёрке 4 байта мейджика хватало для кодирования чего угодно, а теперь целых 8. Было бы желание.
На самом деле используется не 64 а всего 63 бита ( то есть неполные 8 байт). 8 байт было бы, если использовать весь диапазон long.
Но к сожалению...
С одной стороны в структуру MqlTradeRequest передаётся ulong magic. Это означает, что задавать можно только положительные значения.
С другой стороны функции PositionGetInteger/OrderGetInteger возвращают тип long. Это означает, что половина диапазона ulong отсекается.
Итого вместо заявленных 64 бит имеем по факту 63. В общем-то, это не столько плохо - сколько привносит большие неудобства в принципы контроля ордеров.
Намного удобнее оставить аналогичную систему как в МТ4 - разрешить магики со знаком. Так как много торговых систем построено на простом принципе с использованием именно знака магика. Так ведь намного проще разделить одну систему на две и отфильтровывать свои ордера обычной функцией MathAbs( OrderMagicNumber() )
На самом деле используется не 64 а всего 63 бита ( то есть неполные 8 байт). 8 байт было бы, если использовать весь диапазон long.
Вы ошибаетесь.
Используется 64 бита и только от Вас зависит как Вы их будете применять. long/ulong не имеет никакого значения, все зависит от того, как именно Вы будете интерпретировать эти 64 бита. Хотите использовать как знаковый long - используйте, хотите как беззнаковый ulong - используйте без проблем. Хотите упаковать другие типы данных в эти 64 бита - упаковывайте.
Именно об этом написал Слава.
На самом деле используется не 64 а всего 63 бита ( то есть неполные 8 байт). 8 байт было бы, если использовать весь диапазон long.
Но к сожалению...
С одной стороны в структуру MqlTradeRequest передаётся ulong magic. Это означает, что задавать можно только положительные значения.
С другой стороны функции PositionGetInteger/OrderGetInteger возвращают тип long. Это означает, что половина диапазона ulong отсекается.
Итого вместо заявленных 64 бит имеем по факту 63. В общем-то, это не столько плохо - сколько привносит большие неудобства в принципы контроля ордеров.
Намного удобнее оставить аналогичную систему как в МТ4 - разрешить магики со знаком. Так как много торговых систем построено на простом принципе с использованием именно знака магика. Так ведь намного проще разделить одну систему на две и отфильтровывать свои ордера обычной функцией MathAbs( OrderMagicNumber() )
Мужики, я честно в недоуменьях. Вы паритесь на ровном месте. Абсолютно ровном. Проблемы просто не существует, вы её выдумали. Разберитесь уже с преобразованиями типов до конца.
Надеюсь нижележащий фрагмент вам поможет. Скопируйте его в скрипт, скомпилируйте, обязательно выполните в терминале, и потом очень тщательно подумайте. Успехов.