Справочная информация: если вы никогда не используете функцию OrderSendAsync(), а вместо этого всегда используете функцию OrderSend(), проблем не возникает.
Но если вы хотите ускорить процесс и использовать функцию OrderSendAsync(), возникает проблема: на момент возврата функции OrderSendAsync() сервер еще не обработал ваш заказ. И в этом весь смысл существования функции OrderSendAsync()! Это означает, что поскольку сервер еще не обработал ваш заказ, то и билет ulong еще не назначен.
Таким образом, невозможно сопоставить ордера, отправленные с помощью функции OrderSendAsync(), и сделки, совершенные в результате этих ордеров.
Многие другие MQL5-функции принимают параметр ulong ticket, например метод CTrade PositionClose:
bool PositionClose(const ulong ticket,const ulong deviation=ULONG_MAX);
Именно из-за этой дилеммы многие коммерческие документы имеют ДВА поля: «Наша ссылка» и «Ваша ссылка».
Функция OrderSendAsync() действительно должна была быть спроектирована таким образом, чтобы в качестве поля ввода она имела "Справочник клиента", а затем в MQL5 должна была быть включена вспомогательная функция, которая принимает на вход "Справочник клиента" и выдает "Справочник брокера" как результат.
К сожалению, MetaQuotes corp. пропустил эту деталь, что сделало функцию OrderSendAsync() менее полезной, чем она должна быть.
Я представлю одно возможное решение этой проблемы, но в то же время я хочу спросить: кто-нибудь придумал лучшее решение этой же проблемы.
Возможное решение: используйте 64-битное магическое значение способом, отличным от того, для чего оно изначально предназначалось:
Структура MqlTradeRequest (параметр OrderSendAsync) содержит это поле: ulong magic; // Expert Advisor ID (magic number)
Используйте только старшие 32 бита этой магии в качестве «идентификатора советника». Затем используйте младшие 32 бита этой магии в качестве «Ссылки на клиента».
К сожалению, это означает, что класс CTrade нуждается в значительном изменении дизайна из-за того, что вместо того, чтобы использовать магическое число как одно 64-битное целое число, теперь оно используется как контейнер для двух отдельных 32-битных целых чисел.
Итак, хотя приведенное выше может быть одним из возможных решений этой проблемы:
Кто-нибудь придумал лучшее решение этой же проблемы?
