OrderSendAsync() function - page 5

[Denis Kirichenko]

Urain:

If your proposal would only complement an existing function then nothing, otherwise it's not clear how a simple MqlPacketTradeRequest structure ...

... If MqlPacketTradeRequest structure is the structure of dynamic array of MqlTradeRequest structures, it may break the entire logic of server flooded with simple query structures.

Otherwise, at the terminal level, we'd have to split this packet into separate requests, which would negate the whole point of introducing this overload.

It seems that we "agreed" on such a variant because of asynchronous structure:

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

Where,

packet_request will include among other things an array of MqlTradeRequest structures...

Then all these thoughts are raw material for discussion :-)

[Yedelkin]

Urain:

IMHO a batch of identical applications is needed only for demonstration purposes, for work applications of different symbols, with different volumes and of course different directions will be used. And therefore each reguest will have to be checked separately, so there is no point in sending them in a batch.

Well, you have to choose here: one-time start of function OrderSendPacketAsync(MqTradeRequest& request[], MqlPacketTradeResult& packet_result) which sends a prefilled array request[] of 500 elements at a time with one-time check of return code 10008, or a 500-time start of the OrderSendAsync() function with a 500-time check of the return code 10008.

[Yedelkin]

Urain:

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

How can a trade request using a dynamic array "break the server's logic"? If I have a block, that processes a variable of a certain type of structure, then what prevents me from applying this block to each element of an array of the same type? Similarly, if nowadays a server is "geared to simple query structures", what prevents me from adding a loop, that when a server accepts a dynamic array sent by OrderSendPacketAsync() function, it will allow to apply in turn a block "geared to simple query structures" to each element of such an array?

[Yedelkin]

papaklass:

In my opinion, the OrderSendAsync() function should be made parametric instead of creating a loop for sending orders. For example OrderSendAsync(Symbol(), number, direction). As parameters: - symbol, - numberof orders, - direction of orders (buy, sell).

This is similar to a special case of sending a mass trade request using a dynamic array and the OrderSendPacketAsync() function, when the'symbol' and 'type' fields are the same foreach element of the dynamic array .

[Yedelkin]

When conducting asynchronous trades, we do not know exactly how any particular request was triggered. In particular, we do not know how much volume was outstanding when one of the asynchronous requests was partially executed.

Can you please tell me if I understand correctly that both in forex trading and in stock trading, the order from history property

ORDER_VOLUME_CURRENT

Unfilled volume

allows us to unambiguously determine how fully an asynchronous request was executed? I.e., is it correct that when a market order is sent asynchronously in the forex market, when it appears in the history, we can be sure that if ORDER_VOLUME_CURRENT==0.0, the order has been completely executed, but if ORDER_VOLUME_CURRENT contains a non-zero value, then this value should be considered as the unfilled volume for that forex market order?

The question is prompted by the fact that here: https://www.mql5.com/ru/forum/3775/page28#comment_84851 emphasizes that the ORDER_VOLUME_CURRENT property refers to orders used in the stock market.

[Yedelkin]

Question regarding the asynchronous request appearing in the history.

When OrderSendAsync() returns true and result.retcode field contains 10008, then according to the Reference, it "means that the request was sent, but does not guarantee that it reached the trading server".

Question: if an asynchronous request is successfully sent by the terminal, but doesn't reach the server, will such a request always end up in the history? In other words, can it happen that an asynchronous request is successfully (by all indications) sent to the server, but information about it won't appear in the history? If this scenario is possible, under what conditions?

[Renat Fatkhullin]

Yedelkin:

Question: if an asynchronous request was successfully sent by the terminal, but didn't reach the server, will information about such a request always appear in the history? In other words, can it happen that an asynchronous request is sent to the server successfully (in all respects), but information about it does not appear in the history? If this scenario is possible, under what conditions?

If the request does not reach the server, it has no chance to appear in the client terminal.

[Yedelkin]

Renat:
If the request doesn't reach the server, it has no chance of appearing in the client terminal.

Oops! It turns out that a successfully sent asynchronous request can easily get lost and not appear in the history.

[---]

Yedelkin:
Oops! It turns out that a successfully sent asynchronous request can easily get lost and not get into the history.

no.

[Renat Fatkhullin]

Yedelkin:
It turns out that a successfully sent asynchronous request can easily get lost and not get into the history.

The point is that an asynchronous request has practically no "successfully sent" status.

Successful completion of the function only means that the "order looks correct from the client's point of view and was thrown into the network pipe, wait for an answer in OnTrade".