![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
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.
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.
Но для этого придётся дожидаться ответа от сервера в рамках функции OrderSendAsync(). И асинхронность функции OrderSendAsync() сойдёт на нет. Ренат же уже пообещал, что будут иные функции, с помощью которых можно попытаться похимичить после срабатывания OrderSendAsync().
Yes, I hadn't thought about asynchrony...
That's it, then:
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.
Yes, I hadn't thought about asynchrony...
That's it, then:
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.).
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.
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.
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.
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 ...
... 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.