OrderSendAsync() function - page 4

[Denis Kirichenko]

Colleagues, what do you think of this idea? In such a structure(MqlPacketTradeResult) you can write a field indicating the number of completed orders, etc.

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

[Yedelkin]

denkir:

Colleagues, what do you think of this idea? In such a structure(MqlPacketTradeResult) you can write a field indicating the number of completed orders, etc.

But to do this, we would have to wait for a response from the server within OrderSendAsync() function. And OrderSendAsync() function's asynchrony will come to naught. Renat has already promised that there will be other functions which can be used to try to mess around after OrderSendAsync() is triggered.

[Denis Kirichenko]

Yedelkin:
Но для этого придётся дожидаться ответа от сервера в рамках функции OrderSendAsync(). И асинхронность функции OrderSendAsync() сойдёт на нет. Ренат же уже пообещал, что будут иные функции, с помощью которых можно попытаться похимичить после срабатывания OrderSendAsync().

Yes, I hadn't thought about asynchrony...

That's it, then:

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

bool  OrderReceiveAsync(
   MqlPacketTradeResult&   packet_result        // пакетная структура ответа
   );

[Rashid Umarov]

denkir:

Yes, I hadn't thought about asynchrony...

Well, here goes:

Asynchronous means working without waiting for a response. Fire (OrderSenAsync) and run without trying to see if the target is hit. For there is no time.

An indirect response would be a sound coming later (OnTrade) - maybe the shot hit the target, or maybe something just fell down. This is where you can look out and see (check all orders, trades, positions, etc.) if you wish.

[Yedelkin]

denkir:

Yes, I hadn't thought about asynchrony...

That's it, then:

Well, then already OrderSendPacketAsync(), OrderReceivePacketAsync :) So that it's still possible to send a single request in already existing asynchronous mode, and look for information about it afterwards.

[Yedelkin]

Rosh:

An indirect answer is a sound that comes later (OnTrade) - maybe the shot has reached the target, or maybe something has just fallen. This is where you can look out if you wish (check all orders, trades, positions, etc.).

So, he suggests using in OnTrade() some function OrderReceiveXXX() to enable us to react not to all incoming Trade events but only to those that belong to asynchronous queues.

[hrenfx]

Rosh:

Asynchronous means working without waiting for a response. Fire (OrderSenAsync) and run without trying to see if the target is hit. For there is no time.

An indirect answer is a later sound (OnTrade) - it may be that the shot hit the target or something just fell down. This is where you can look out if you want to (check all orders, trades, positions, etc.).

You are wrong either because of your little experience in asynchronous mode trading or because of the weak functionality of MT5 for such kind of operation.

You don't need asynchrony for the sake of asynchrony. And it's used only when it's profitable. For example, when trading a portfolio, when the portfolio needs to be bought or rebalanced here and now. In other words, a dozen or so trade orders for different symbols at the current prices.

And no one will do it, if you treat asynchrony the way you described - shoot and forget. And the reactions to the shots should be assessed on the basis of current net positions. The reactions should be specific to each trade order.

If there was a redirect, we should be told about it or we should get another response. We should not guess if there was a rebid or not, since the net position has not changed for a second or two.

On the first page of this discussion there are diagrams and incoming message-events. They didn't just appear out of thin air, but with years of asynchronous experience. So it is worth paying attention to such architecture without squeamishness.

[Mykola Demko]

denkir:

Colleagues, what do you think of this idea? In such a structure(MqlPacketTradeResult) you can write a field indicating the number of completed orders, etc.

You assume that the batch of orders always has the same fields?

IMHO a batch of identical requests is needed only for demonstration purposes, for the work will be used requests of different symbols with different volumes and of course different directions. And consequently each reguest will have to be checked separately, so there is no sense to send them a batch.

And what you assume is just a binding of the for loop.

[Denis Kirichenko]

Urain:

Are you suggesting that a stack of applications always has the same fields filled in?

IMHO a batch of identical applications is only needed for demonstration purposes, applications with different characters, different volumes and of course different directions will be used for work. And consequently each reguest will have to be checked separately, so there is no sense to send them a batch.

And what you assume is just a binding of the for loop.

And what prevents you from filling each reguest cyclically? And then just as cyclically process each result?

[Mykola Demko]

denkir:
What prevents them from filling each reguest cyclically? And then just as cyclically process each result?

If your proposal will only compliment the existing function, nothing, otherwise it's not clear how simple structure MqlPacketTradeRequest ...

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

... If MqlPacketTradeRequest structure is the structure of dynamic array of MqlTradeRequest structures, it can break all logic of the server which is designed for simple query structures.

Otherwise, at the terminal level we would have to split this batch into separate requests, which nullifies the whole point of introducing this overload.