Функция OrderSendAsync() - страница 5

[Denis Kirichenko]

Urain:

Если ваше предложение будет лишь дополнять существующую функцию то ничего, иначе не понятно как простая структура MqlPacketTradeRequest ...

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

иначе говоря на уровне терминала придётся разделить этот пакет на отдельные заявки, что сводит на нет весь смысл введения данной перегрузки.

Вроде "договорились" на такой вариант из-за асинхронности:

bool  OrderSendAsync(
   MqlPacketTradeRequest&  packet_request,      // пакетная структура запроса
   );

где,

packet_request будет включать кроме всего прочего  массив структур MqlTradeRequest...

Потом все эти мысли - сырьё для обсуждения :-)

[Yedelkin]

Urain:

ИМХО пачка одинаковых заявок нужна лишь для демонстрации, для работы будет использоваться заявки по разным символам, с разными объёмами и конечно разного направления. А следовательно каждый reguest придётся в отдельности проверить, так что смысла отправлять их пачкой нет.

Ну, здесь надо выбирать: или одноразовый запуск функции OrderSendPacketAsync(MqTradeRequest& request[], MqlPacketTradeResult&   packet_result), отправляющей за один раз предварительно заполненный массив request[] из 500 элементов с однократной проверкой кода возврата 10008, или 500-кратный запуск функции OrderSendAsync() с 500-кратной проверкой кода возврата 10008.

[Yedelkin]

Urain:

... если же структура MqlPacketTradeRequest есть структура динамичного массива структур MqlTradeRequest то это может поломать всю логику сервера который заточен под простые структуры запросов.

Каким образом торговый запрос с помощью динамического массива может "поломать логику сервера"? Если у меня есть блок, обрабатывающий переменную типа определённой структуры, то что мне мешает при необходимости применить этот блок к каждому элементу массива того же типа? Аналогично, если нынче "сервер заточен под простые структуры запросов", то что мешает дописать цикл, который при принятии сервером динамического массива, отправленного функцией OrderSendPacketAsync(), позволит поочерёдно применить к каждому элементу такого массива блок, "заточенный под простые структуры запросов"?

[Yedelkin]

papaklass:

На мой взгляд, функцию OrderSendAsync() нужно делать параметрической, вместо организации цикла по отсылке ордеров. Например OrderSendAsync(Symbol(), number, direction). В качестве параметров: - символ, -количество ордеров, -направление ордеров (buy, sell).

Это похоже на частный случай однократной отправки массового торгового запроса с помощью динамического массива и функции OrderSendPacketAsync(), когда одинаковыми являются поля "symbol" и "type" у каждого элемента динамического массива.

[Yedelkin]

При проведении асинхронных торговых операций мы не знаем, каким именно образом сработал тот или иной запрос. В частности, мы не знаем, какой объём оказался невыполненным при частичном исполнении одного из асинхронных запросов. 

Подскажите, правильно ли я понимаю, что и при торговле на форексе, и при торговле на биржевом рынке свойство ордера из истории

ORDER_VOLUME_CURRENT

Невыполненный объём

позволяет однозначно определить, насколько полно был выполнен асинхронный запрос? Т.е., правильно ли, что когда на форексе асинхронно отправляется рыночный ордер, то при появлении его в истории можно гарантированно утверждать, что если ORDER_VOLUME_CURRENT==0.0, то ордер выполнен полностью, а если ORDER_VOLUME_CURRENT содержит ненулевое значение, то именно это значение следует считать невыполненным объёмом для такого форексного рыночного ордера?

Вопрос вызван тем, что вот здесь: https://www.mql5.com/ru/forum/3775/page28#comment_84851 делается акцент на то, что свойство ORDER_VOLUME_CURRENT относится к ордерам, используемым на фондовом рынке.

[Yedelkin]

Вопрос относительно появления в истории сведений об асинхронном запросе.

Когда функция OrderSendAsync() возвращает true, а поле result.retcode содержит код 10008, то, согласно Справочнику, это "означает  только факт отсылки, но не даёт никакой гарантии, что запрос дошёл до торгового сервера".

Вопрос: если асинхронный запрос успешно отослан терминалом, но не дошёл до сервера, то всегда ли сведения о таком запросе попадут в историю? Иными словами, может ли случиться так, что асинхронный запрос успешно (по всем показателям) будет отправлен на сервер, но сведения о нём не появятся в истории? Если таковой сценарий возможен, то при каких условиях?

[Renat Fatkhullin]

Yedelkin:

Вопрос: если асинхронный запрос успешно отослан терминалом, но не дошёл до сервера, то всегда ли сведения о таком запросе попадут в историю? Иными словами, может ли случиться так, что асинхронный запрос успешно (по всем показателям) будет отправлен на сервер, но сведения о нём не появятся в истории? Если таковой сценарий возможен, то при каких условиях?

Если запрос не дошел до сервера, то в клиентском терминале у него нет никаких шансов появиться.

[Yedelkin]

Renat:
Если запрос не дошел до сервера, то в клиентском терминале у него нет никаких шансов появиться.

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

[---]

Yedelkin:
Спс! Получается, что удачно отправленный асинхронный запрос может запросто потеряться и не попасть в историю.

нет.

[Renat Fatkhullin]

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

В том то и дело, что асинхронный запрос никакого статуса "удачно отправленный" практически не дает.

Успешное завершение функции означает лишь что "с точки зрения клиента ордер выглядит корректным и был брошен в сетевую трубу, ответ ждите в OnTrade".