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
Technical message. Gathering interesting statements into one topic.
sergeev:
Yedelkin:
Which account property will be responsible for the limit of simultaneous orders in the execution queue? Will it be possible to find out this figure programmatically?
the result of the OrderSendAsync = false function will simply be
use it as a guide
Reread the thread with interest, and even tested it in practice, and here I discovered the blatant discrimination of automatic trading.
Here is the log of manual position closing: (understandable chronology from bottom to top)
What we see here: the order is sent, order is accepted, a ticket is assigned to the order, and finally the order is executed (there may be some shifts in interpretation, but that's about it). Everything is classic.
The only strange thing is that the Trades event knows for sure (within the terminal) by which category it was triggered, as well as by which order (for the last two categories); otherwise it would be impossible to output such comment, and the programmer would have to re-invent the wheel to obtain this information. And the situation with the OrderSendAsync function did not add any simplicity at all.
However, we should note that the speed of order execution has increased. Now we don't have time to notice the order being put in the queue, and it has already been executed.
So we have a pack of orders, each of which theoretically comes 4 Trades, in each of the Trades we would need to control each order.
Thus, we have 4*Number_Order*Number_Order control points, i.e. we have 400 for 10 orders and 40000 for 100. And God forbid, any order would have less amount of Trades than 4, then the entire control logic collapses, since waiting before sending a second order (if the first request is not executed) takes place exactly on number 4.
You have sent a stack of trade orders to the server.
For each order, do you need to keep a separate execution check? And how long do we wait for a response?
Does each order have to be monitored separately?
Yes
And how long do I have to wait for a response?
yeah
They do not have the same function for different brokers. If STP, then it's more a question for their liquidity provider.No, it's all guessing by coffee grounds. When you open the window manually, you press buy, wait for a requote or execution, press ok and you're done.
When you open in auto mode, there should also be a reference point, from which you have to send a second request or everything is OK.
SZS added to the post above, reread.
No, it's all guesswork, when you manually open a window, press buy, wait for a requote or execution, press ok and you're done.
No. This is the case when the return code is DONE(10009).
But there are brokers who pass your trade on to the provider. And in this case they will return you immediately PLACED(10008). And by the way, if it was a market order, there will be no Deal ticket in this response. Only the order ticket.
And there won't even be a ticket for the order in case of OrderSendAsync.
In the auto mode, so should be the reference point, from which you want to send a second request, or everything is OK.
Well, what is the reference point at requotes even on MT4? You will not make an endless loop and wait for the deletion or opening of an order.
Everything is ticketype, with checks of saved states, etc.
Tried to run the OrderSendAsync() function
It responded with
2012.05.02 21:12:33 OrderSendAsync (USDCHF,M1) retcode=10008, order=0, deal=0
A quick question arises: how do we plan to trace the fate of a trade request when it is sent using the OrderSendAsync() function, if we don't even know the order ticket? The comment must be filled out by the broker.
Track the execution of asynchronous transactions in OnTrade. Yes, this is a more complicated path, but that is the price of asynchrony.
Asynchronous mode is designed for bulk batch order entry, but not for a single transaction. For a single transaction it is better to use synchronous mode - everything will be executed at the same speed and with full service.
Track the execution of asynchronous transactions in OnTrade. Yes, it's a more complicated way, but that's the price of asynchrony.
1) does not guarantee timeliness or even availability of response
2) clearly requires separate queues of operations by the developer
In other words, we have to generate a list of orders and then check and fill them within OnTrade. This, of course, is excruciating.
For our part, we could transparently maintain asynchronous queues, fill them with answers and provide traders with convenient functions to check and retrieve processed entries from the queue. You can check the queues asynchronously in OnTrade or synchronously by polling in the loop right after sending a batch of orders.
We will think about such a mechanism - it would make life easier for EA developers by relieving them of their routine.