Вопросы от "чайника" - страница 12
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
ПОДСКАЖИТЕ ПОЖАЙЛУСТА ПО МОБИЛЬНОМУ ТЕРМИНАЛУ.
КОГДА И БУДЕТ ЛИ ВООБЩЕ РЕАЛИЗОВАНА ПОДДЕРЖКА ПОЛЬЗОВАТЕЛЬСКИХ ИНДИКАТОРОВ (НЕ СТАНДАРТНЫХ) ИЛИ СОВЕТНИКОВ НА mql4 ИЛИ mql5?????????????????????????????
НА КАКИХ ПЛАТФОРМАХ (АНДРОИД НАПРИМЕР) ЭТО БУДЕТ РЕАЛИЗОВАНО????????????????? И КАК СКОРО?????????????
жду ОТВЕТА, СПАСИБО ЗА ВНИМАНИЕ
Interesting:
Ну вот не согласен с таким выводом. ОСО == "один отменяет другой". Ну нет в МТ5 такого, чтобы один ордер реально отменял другой. О чём и сожалею уже с год. ...Такие возможности, как SL и TP, реально закрывают открытую позицию, но к вопросу "взаимоотмены" отложеных ордеров не имеют отношения.
Имеют как раз, но это ордера реализованные на сервере. И единственыне пока реально вписанные в схему OCO (а про "If Done" реализованных напрямую в терминале и сервере мечтать пока не приходится).
Открывая позицию и выставляя TP и SL в МТ5 мы по сути знаполняем примерно такую форму (только тут результатом становится позиция + 2 взаимоотменяемых ордера).
После Вашего сообщения я уже прокомментировал немного ситуацию с учётом ссылок на взаимоотменяемость SL и TP. Здесь же хотелось бы добавить следующее.
Если бы авторам OCO-ордеров рассказали, что в 21 веке их изобретение будет применяться исключительно к уровням SL и TP, они бы очень удивились такому ограничению области применения их детища :) ...Фактически же, всё повернуто с ног на голову. Какие бы материалы не читал, везде речь идёт об одном: ОСО-ордера представляют собой взаимотменяемые ордера, типы которых отражены нынче в MQL5-перечислении ENUM_ORDER_TYPE. Ни разу не встречал упоминания про связь ОСО-ордеров и уровней SL-TP. Т.е. механизм исполнения может быть тот же, но ОСО-ордера оформлялись клиентом исходя именно из ордеров ENUM_ORDER_TYPE, а не из уровней SL-TP (по версии MQ).
Поэтому, когда пишу про отложенные ордера, имею в виду ордера из перечисления ENUM_ORDER_TYPE, а не "производные"* ордера по уровням SL-TP.
______________
* "производные" - потому, что каждый из OCO-ордеров может иметь свои уровни SL-TP.
Господа, корень понимания лежит в простоте платформы. Простоте для 99% пользователей с осознанным отказом от усложнений, в которых может разобраться оставшийся процент пользователей.
Задайте себе вопрос "что нужно сделать, чтобы привлечь X млн пользователей на финансовые рынки?". При наличии достаточного уровня опыта ответ будет близкий к "сделать простую систему, убрав сложности и объединить трейдеров единой экосистемой".
Вместо нагромождения настроек ОСО ордеров (панель реально не для среднего ума) мы предложили очень простую и понятную схему управления ордерами с интегрированными SL/TP. Подавляющее большинство OCO ордеров - это как раз SL/TP для текущих позиций. Путем внесения SL/TP внутрь мы минимизировали количество дополнительных ордеров и сильно упростили управление сделками.
ps: вопрос ордерной системы закрыт
ps: вопрос ордерной системы закрыт
ps: вопрос ордерной системы закрыт
Очень жаль, что не получится сделать нормальные (надежные) СЛ/ТП для отдельных сделок (не суммарной позиции).
Это сразу отсекает возможность (надежно) торговать по нескольким стратегиям на одном инструменте/счете.
Хали-вор предлагаю не возобновлять, мнение разработчиков (один инструмент = одна позиция = один СЛ и один ТП) я помню...
К какому типу (long или ulong) фактически относится ORDER_MAGIC?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
Идентификатор эксперта выставившего ордер (предназначен для того, чтобы каждый эксперт выставлял свой собственный уникальный номер)
long
К какому типу (long или ulong) фактически относится ORDER_MAGIC?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
Идентификатор эксперта выставившего ордер (предназначен для того, чтобы каждый эксперт выставлял свой собственный уникальный номер)
long
Преобразовывать результат на мой ззгляд следует к объявленному в коде типу (в документации может быть и опечатка).
Если говарить от MqlTradeRequest то в данном случае это скорей всего (ulong) хотя возможно без замечаний прокатит и long.
Преобразовывать результат на мой ззгляд следует к объявленному в коде типу (в документации может быть и опечатка).
Если говарить от MqlTradeRequest то в данном случае это скорей всего (ulong) хотя возможно без замечаний прокатит и long.
В общем, ответ не по существу. Вопрос был конкретный: "к какому типу (long или ulong) фактически относится ORDER_MAGIC?"
Давайте попробуем по существу:
1. Объявлять можно оба этих типа без преобразований.
2. Если пользоваться только положительными значениями магика то выгодней указывать его значение как ulong (поскольку там диапазон возможных значений от 0 до 18 446 744 073 709 551 615).
3. С другой стороны в классе CExpert, стандартной библиотеки при инициализации применяется значение long (что позволяет указывать отрицательные величины но смещает диапазон возможных значений). Таким образом при инициализации данного класса значение магика уже может быть от -9 223 372 036 854 775 808 до 9 223 372 036 854 775 808.
Данное утверждение следует проверить.
4. Но уже в классе CTrade (все той же стандартной библиотеки) магик как и положено на основании структуры запроса имеет значение ulong.
Сделаем предварительные выводы:
а) Работа с магиком в классах CExpert и CTrade не согласованна, поскольку в одном случае указывается long, а в другом ulong;
б) Данные классы разрабатывали разные люди, либо состав и структура параметров определенных функций у CExpert закладывались без учета функционала CTrade (того могло еще в природе и не быть).
в) Работа специалистов связанных с разработкой и документированием стандартной библиотеки не до конца согласована (хотя в основном видна достаточно хорошая проработка ключевых вопросов).
г) Если я правильно понимаю то взаимодействие двух этих классов ограничивает значение магика диапазоном от 0 до 9 223 372 036 854 775 808. Данное утверждение следует проверить.
5. Структура MqlTradeRequest имеет тип ulong для работы с магиком. Тут все полностью согласовано с классом CTrade, поэтому если пользоваться только этим классом то диапазон возможных значений магика логично указывать в пределах от 0 до 18 446 744 073 709 551 615. Данное утверждение следует проверить.
PS
Вообще странно все это. такое впчечатление что разработчики намеренно "зажали" возможные значения магика в диапазон от 0 до 9 223 372 036 854 775 808.
Вообще странно все это. такое впчечатление что разработчики намеренно "зажали" возможные значения магика в диапазон от 0 до 9 223 372 036 854 775 808.
Вообще-то, под мейджик отдано целых 8 байт информации, которую можно интерпретировать как угодно. Хоть datetime, хоть double, хоть 4 short, хоть 8 char, хоть 64 бита побитно.
В четвёрке 4 байта мейджика хватало для кодирования чего угодно, а теперь целых 8. Было бы желание.