OrderSend() Вопросы - страница 6

 
maryan.dirtyn:

сламал себе всю голову.. не ставит стоп и все тут.. и куча ошибок. уже вот что осталось от експерта, и дальше не работает

 если сделать так, то ошибок нету, но стоплосс все равно не устанавливается

Ответил тут
 
Yedelkin:

Видимо, не совсем доходчиво пояснил предыдущую проблему. Попробую ещё раз.

За последний год описание списка значений перечисления ENUM_ORDER_TYPE_FILLING менялось, как минимум, трижды.   Предыдущее описание выглядело так:

ENUM_ORDER_TYPE_FILLING

Идентификатор

Описание

ORDER_FILLING_FOK

Сделка может быть совершена исключительно в указанном объеме и по цене равной или лучше указанной в ордере. Если на рынке в данный момент не присутствует достаточного объема предложений по символу ордера, то ордер не будет исполнен. Данный тип заполнения используется в режиме исполнения SYMBOL_TRADE_EXECUTION_INSTANT или SYMBOL_TRADE_EXECUTION_REQUEST.

ORDER_FILLING_IOC

Согласие совершить сделку по максимально доступному на рынке объему в пределах указанного в ордере и по цене равной или лучшей указанной. При этом на недостающий объем дополнительные ордера не выставляются. Данный тип заполнения может быть доступен только в режимах исполнения SYMBOL_TRADE_EXECUTION_MARKET и SYMBOL_TRADE_EXECUTION_EXCHANGE в зависимости от настроек символа на торговом сервере.

ORDER_FILLING_RETURN

Согласие совершить сделку по максимально доступному на рынке объему в пределах указанного в ордере и цене равной или лучше указанной. При этом на недостающий объем будет выставлен дополнительный ордер по цене, указанной в данном ордере. Данный тип заполнения используется только для отложенных ордеров (TRADE_ACTION_PENDING).

Как нетрудно заметить, существовало взаимно-однозначное соответствие между ORDER_FILLING_RETURN и отложенными ордерами, а именно: ORDER_FILLING_RETURN могло применяться только к отложенным ордерам, и поле type_filling  всех отложенных ордеров могло заполняться только значением ORDER_FILLING_RETURN.

Для рыночных ордеров (action==TRADE_ACTION_DEAL) поле type_filling  необходимо было заполнять в зависимости от режимов исполнения, установленных на стороне сервера.

Тем самым, складывалась некая парадигма: если отложенный ордер, то  ORDER_FILLING_RETURN; если рыночный ордер, то ORDER_FILLING_FOK или ORDER_FILLING_IOC (в зависимости от режима).

Теперь же всё поставлено несколько с ног на голову, а именно:

ENUM_ORDER_TYPE_FILLING

Идентификатор

Описание

ORDER_FILLING_FOK

Данная политика исполнения означает, что ордер может быть исполнен исключительно в указанном объеме. Если на рынке в данный момент не присутствует достаточного объема финансового инструмента, то ордер не будет исполнен. Необходимый объем может быть составлен из нескольких предложений, доступных в данный момент на рынке.

ORDER_FILLING_IOC

Означает согласие совершить сделку по максимально доступному на рынке объему в пределах указанного в ордере. В случае невозможности полного исполнения ордер будет исполнен на доступный объем, а неисполненный объем ордера будет отменен.

ORDER_FILLING_RETURN

Данный режим используется только для ордеров ORDER_TYPE_BUY_LIMIT и ORDER_TYPE_SELL_LIMIT. В случае частичного исполнения лимитный ордер с остаточным объемом не снимается, а продолжает действовать.

Для ордеров ORDER_TYPE_BUY_STOP_LIMIT и ORDER_TYPE_SELL_STOP_LIMIT при активации будет создан соответствующий лимитный ордер ORDER_TYPE_BUY_LIMIT/ORDER_TYPE_SELL_LIMIT с типом исполнения ORDER_FILLING_RETURN.

Ограничение на использование ORDER_FILLING_FOK и ORDER_FILLING_IOC только с рыночными ордерами - исчезло. Исчезло также ограничение на использование ORDER_FILLING_FOK и ORDER_FILLING_IOC с рыночными ордерами в зависимости от режима исполнения, установленного на сервере. Появилось ограничение на использование ORDER_FILLING_RETURN только с limit- и stop_limit-ордерами.

Поэтому и вопрос: Является ли допустимым применение режимов ORDER_FILLING_FOK и ORDER_FILLING_IOC вообще к всем ордерам (как рыночным, так и отложенным), в том числе и к limit- и stop_limit-ордерам? Кто-нибудь разобрался в изменениях? 

Да уж, в этом вопросе мутновато.

Если есть полное соответствие между ENUM_SYMBOL_TRADE_EXECUTION и ENUM_ORDER_TYPE_FILLING то второе явно лишнее, можно было бы просто по типу символа подставлять нужную информацию терминалом.

Отсюда мораль соответствия нет, а вероятнее всего, при одном и том же значении ENUM_SYMBOL_TRADE_EXECUTION допустимы разные значения ENUM_ORDER_TYPE_FILLING. Тут бы MQ описать таблицу возможных вариантов, но скорее всего эти данные зависимы от настроек сервера диллинга.

А отсюда вторая мораль, что же всё таки нужно:

а нужна функция которая возвращала бы перечень допустимых вариантов (ENUM_ORDER_TYPE_FILLING), для запрошенного типа ордера (немедленный или отложенный).

Вариантов там не много, поэтому можно пихануть в int через "|".

Если я не прав, до дайте волшебный пендель, куда курить чтоб вкурить этот вопрос.



 

Чтоб разгрести этот вопрос полез в стандартную библиотеку (по привычке, если чего не понятно посмотреть как другие делают).

Там вообще ужоС, этот вопрос вообще не обрабатывается, дали функцию для комфортного наследования, а в самом классе CTrade SetTypeFilling() не используется, поле type_filling инициализируется умолчательным нулём, что по перечислению соответствует ORDER_FILLING_FOK.

И всё, больше ни каких телодвижений. А я то думал, раз в интерфейсе этого поля нет, значит в классе заполнение автоматизированно.

ЗЫ в общем ждём ответа, как разгребать это :)
 
Пока что, мне видится один выход: долбить сервер пока не дождешься от него нужного ответа.
 
her.human:
Пока что, мне видится один выход: долбить сервер пока не дождешься от него нужного ответа.

Порадовал на ночь глядя, смеялся до коликов в животе.

Китайцы взломали центральный сервер Пентагона.

Каждый китаец попробовал один раз набрать пароль.

Каждый второй набирал "Мао Цзе Дун".

На 5*10^7 попытке сервер согласился, что пароль "Мао Цзе Дун"

 
her.human:
Пока что, мне видится один выход: долбить сервер пока не дождешься от него нужного ответа.

глупый выход.

вы со своим ДЦ поговорите для начала. узнайте какие типы исполнения они поддерживают и какие типы метаквотовского списка соответствуют типам их исполнения.

так как то, что метаквоты придумали - 3 типа заливки и 3 типа времени - это еще не значит, что они являются отражением реальности при заливке ордеров на реальном брокере.

 
sergeev:

глупый выход.

вы со своим ДЦ поговорите для начала. узнайте какие типы исполнения они поддерживают и какие типы метаквотовского списка соответствуют типам их исполнения.

так как то, что метаквоты придумали - 3 типа заливки и 3 типа времени - это еще не значит, что они являются отражением реальности при заливке ордеров на реальном брокере.

    Вот и я о том же, всё зависит от настроек сервака,

но стучать в каждый ДЦ тоже проблемно,

ну в один программист постучит, ну в другой,

но обходить все и писать switch диллингов в своём коде это перебор.

    PS согласись что нормальный код пишется унифицированно, под любой диллинг,

возможны исключения но во первых исключения только подтверждают правила, а во вторых если есть исключения нужно писать исключения.

Вот такая тавтология получается.

 
Urain:

Вот и я о том же, всё зависит от настроек сервака,

но стучать в каждый ДЦ тоже проблемно,

ну в один программист постучит, в другой,

но обходить все и писать switch диллингов в своём коде это перебор.

PS согласись что нормальный код пишется унифицированно, под любой диллинг,

возможны исключения но во первых исключения только подтверждают правила, а во вторых если есть исключения нужно писать исключения. Вот такая тавтология получается.

понимаешь тут какое дело.

метаквоты напутали с типами исполнений и времени исполнения.  они нестандартны в том плане, что в реале  IOC и FOK ордера относятся к времени исполнения.

тип исполнения у ордера ранее был адекватным названием - AON.  но его потом убрали.

вот посмотри на FIX спецификацию, по которой работает ДЦ и выполняет заливку ордеров

FIX 4.4 : TimeInForce <59> field

Type: char

Used In
Description

Specifies how long the order remains in effect. Absence of this field is interpreted as DAY. NOTE not applicable to CIV Orders.

Valid values:
0 = Day (or session)
1 = Good Till Cancel (GTC)
2 = At the Opening (OPG)
3 = Immediate or Cancel (IOC)
4 = Fill or Kill (FOK)
5 = Good Till Crossing (GTX)
6 = Good Till Date
7 = At the Close

Я выделил типы, которые взяли метаквоты к себе.  но как ты можешь тут видеть - они все идут в одной группе тега TimeInForce <59>

И вот скажи пожалуйста - как брокеру который выкидывает заявки на рынок   обрабатывать поставленный тип IOC и время GTD в МТ ордере. Ведь у него это одно поле, а не два разных.

Поэтому каждый брокер будет думать уже сам - что ему делать с заливкой и какой тип применять.  И как снимать ордер.


Единственное, что тут приходит во спасение - так это то, что есть разница между рыночным и отложенным ордером.  То есть некторые типы исполнения идут только для отложек  а для маркетных другие.  Вобщем тут смотреть и общаться надо.


А то что называется All-Or-Nothing  находится совсем в другом теге  ExecInst <18>,   тега, который в МТ ордере ваще никак не передается. Он косвенно предполагается (вероятно) для типа FOK

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
sergeev:
...

Алекс возьми эту тему на контроль пожалуйста. Я к сожалению плаваю в этих вопросах.

Сделай предложения в СД, пообщайся с ними.

нужно в теме навести какой то порядок.

А то ведь то что есть сейчас совершенно не юзабельно для профессионального программирования.

 
Urain:

Алекс возьми эту тему на контроль пожалуйста. Я к сожалению плаваю в этих вопросах.
Сделай предложения в СД, пообщайся с ними.
нужно в теме навести какой то порядок.
А то ведь то что есть сейчас совершенно не юзабельно для профессионального программирования.

ха. то ли я дурак, то ли лыжи не едут.

ты же сам видишь, что метаквоты каждый месяц выполняют подключение на новую биржу или рынок.  Соответственно они для этих целей делают мосты.
Из чего я делаю вывод, что в данном положении вещей их программисты стыкуют МТ и FIX без проблем (или с некоторым напрягом с ограничением возможностей одного из них).
То есть совместить тип времени FOK и GTC  у них получается.  А значит в обозримом будущем они наврядли будут что либо менять, так как работа идет.
При этом (я так понимаю), что для биржи мост из МТ может задавать только два типа - AON или Partial. А придуманные в МТ Return - идет вероятно в Partial.

Вобщем вопросы взаимодействия FIX брокера и сервера МТ  лежат в плоскости мастерства и понимания прогеров у брокера, которые делают мосты с МТ на своих провайдеров.  И не думаю что метаквоты будут что либо менять, так как сами уже давно и активно продвигают платформу на рынки, а значит внутренняя структуры работы сервера МТ вполне соответствует реалиям.