OnTradeTransaction - page 2
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
On the one hand, yes. On the other hand: what about cases where a request has been sent to the server, but the operation has not yet been executed? How can we tell what state we are in if we only have a list of orders and positions (and account history)?
There is no such a problem in MT4, because all trading operations there are synchronous. But as a result we get slower performance.
The fact that asynchronous operations are faster than synchronous ones is a myth which comes from ignorance of what is going on. Asynchronous operations have a complete cycle of conducting a trading action divided into several parts, while synchronous ones have only one cycle. Asynchronous operation also requires server's response, execution on exchange is the same, i.e. the total time required for asynchronous and synchronous operation is almost the same. The advantage of asynchronous orders is the possibility to send them simultaneously, i.e. it is possible to send two or more orders at almost the same time. This is what makes it possible to achieve a high speed of operation (in total). Not every Expert Advisor requires asynchronous sending mode. First of all, it is needed for various arbitrage traders where you need to buy two or more symbols at the same time, or HFT algorithms. For example, the HFT bot may send an order to enter the market, and in 3-4 msec it may send the opposite order, in which case it is too long to wait for the server's reply on the first order, so it requires asynchronous mode of sending - without waiting for the result. In the vast majority of EAs such speeds are not necessary.
You don't know how to do it either. You have already written tens of pages about OnTradeTransaction, but haven't understood one thing: OnTradeTransaction is a service function for solving specific tasks, you cannot use it in trading as you do. And then smart guys read your articles and create similar threads: "Why isn't OnTradeTransaction guaranteed?" - because an Expert Advisor should not create its trading environment through OnTradeTransaction, as you do, but rely only on what is available in the system, in particular in the orders and deals history.
And that's where Ostap gets it wrong....
If you have a personal grudge against me, there's no need to bring it into a discussion
of technical problems in which you are "very well versed"...
It's you who mislead people with your pushy theatrics!
And that's where Ostap gets it wrong....
If you have a personal grudge against me, there's no need to bring it into a discussion
of technical problems in which you are "very well versed"...
You're just misleading people with your assertive theories!
Misha, hello! How was your trip to Formula 1? How was the weather in Sochi?
Hi!
Great! Had a swim in the sea (the water was 24 degrees).
Hi!
Great! Had a swim in the sea (the water was 24 degrees).
Cool, that's very warm water!
In all seriousness - I don't have any complaints against you. If you want to argue on the merits - welcome. Moreover, I have no desire to teach someone. Everyone has his own bicycle with square wheels.
If the time between sending the order and the next market entry signal exceeds the order execution time, nothing needs to be done. The logic here is simple: we send an asynchronous order, get out of the thread and forget about it. We wait for the next moment to check for the signal. If at that moment the trading environment has not changed - the Expert Advisor searches for a signal to enter the market again and repeats the order to enter the market. If, on the contrary, everything went well and the order was executed, the Expert Advisor will realize that it has a position after analyzing the environment and will not open a new position again. I.e., in this approach, the Expert Advisor's condition is guaranteed to be consistent with the market environment.
The situation is more complicated in high-frequency trading, where a new signal can occur after a time comparable to the execution of an order (6-100 msec). In this case, you can not do without locking. The Expert Advisor should remember the time of the last order sending. If an error occurs in OnTransaction, the lockout is reset and the Expert Advisor can perform trades again.
It should be noted that OnTradeTransacton that so many people like to pray for does not help at HFT. A new entry signal can arrive faster than the response about successful execution of a transaction in OnTradeTransaction. Blocking is necessary whether you use OnTradeTransacton or not.
How, you may ask, can we control the errors arising in OnTradeTransaction? You can answer with a counter-question: How will you change the trading logic of the Expert Advisor on the fly when an error occurs? - You cannot. Errors occur if you do not make appropriate checks before (presence of money, volume, etc., etc.). But once it has occurred, you will not be able to correct it. Therefore the best thing you can do in OnTradeTransaction, is to print this error into log (to correct logic of Expert Advisor later), and remove the lock, if it is used. For this and nothing else, OnTradeTransaction must be used.
Now various adepts of Mikalas will come running in and start throwing tomatoes at me - let them. But I've always repeated that a reliable trading logic can be organized only if it is based on the trading environment of the terminal. Everything else - doesn't work.
I do not quite understand what does the time between the signals has to do with it? Each trading signal has its registration time. Once the signal is registered (appeared), it is necessary to perform a trading operation. As a result, the Expert Advisor sends a trade order to the server and works further. The order has not been executed by the server yet. A new tick comes. The Expert Advisor re-analyzes its state and discovers that there is an opening signal, but there is no corresponding position (or order) among the working orders.
My question is: how can the Expert Advisor determine without using the data from OnTrade or OnTradeTransaction why there is no position? There may be several reasons:
1. The opening request has been sent to the server, but the server has not yet given an answer on the order execution result. We have to wait for the answer.
2. Request has not been sent to the server yet. Orders need to be sent.
3. Request has been sent, server replies that the order cannot be executed. The error message must be processed and a decision made as to what to do next.
4. Request has been sent, but the server does not respond for a long time (everyone sets this time himself, mine is 1 minute) (timeout).
I don't see any solution without using OnTrade or OnTradeTransaction. But you claim there is one. Please explain which one. Because it is strange to talk about thread locking in MQL4/5 - there are no two or more threads here, there is only one thread. Furthermore, you operate with such expressions as "if everything goes well and the order is executed", but you do not explain how it is determined. And that is the essence of my question.
It is not quite clear what the time between occurrences of signals has to do with it? Each trading signal has its own registration time. Once the signal is registered (occurred), it is necessary to perform a trading operation. As a result, the Expert Advisor sends a trade order to the server and works further. The order has not been executed by the server yet. A new tick comes. The Expert Advisor re-analyzes its state and discovers that there is an opening signal, but there is no corresponding position (or order) among the working orders.
My question is: how can the Expert Advisor determine without using the data from OnTrade or OnTradeTransaction why there is no position? There may be several reasons:
1. The opening request has been sent to the server, but the server has not yet given an answer on the order execution result. We have to wait for the answer.
2. Request has not been sent to the server yet. Orders need to be sent out.
3. Request has been sent, server replies that the order cannot be executed. The error message must be processed and a decision made as to what to do next.
4. Request has been sent, but the server does not respond for a long time (everyone sets this time himself, mine is 1 minute) (timeout).
I don't see any solution without using OnTrade or OnTradeTransaction. But you claim there is one. Please explain which one. Because it is strange to talk about thread locking in MQL4/5 - there are no two or more threads, there is only one thread. Furthermore, you operate with such expressions as "if everything goes well and the order is executed", but you do not explain how it is determined. And that is the essence of my question.
I am not referring to blocking the threads but to blocking the sending of orders.
A double question: suppose an Expert Advisor has determined the reason why a trade order cannot be executed (the market is closed, there is no money, etc.), what next? How will the Expert Advisor improve the situation? Will it add money to the account or open the market? How will knowing the reason for the last order sending error help the Expert Advisor to trade further?
What is meant is not blocking the flow, but blocking the sending of the trade order.
Here's the question: if the server returns an order execution error, how can we find out about it to unblock the ability to send a second order? Again, if OnTrade and OnTradeTransaction are not used.
Another question: Suppose the Expert Advisor has determined the reason why an order cannot be executed (market is closed, there is no money, etc.), what next? How will the Expert Advisor improve the situation? Will it add money to the account or open the market? How will knowing the cause of the last order error help the Expert Advisor to trade further?
It will help a lot. We will leave the lack of money, because the Expert Advisor should determine this point before sending a trade order and notify the trader with a message (or by some other means). Accordingly, the trade order is not sent at all.
The error message can inform us on whether we should continue trying to send orders at all. For example, if the market is closed, there is no need to resend the request immediately. You should stop the trading for some time (it is determined by the Expert Advisor's developer), and only then send a new request (if the trading signal is still active). If a requote occurs, you can send a new request right away. If there was a mistake in setting the stops (Stop Level or Freeze Level has changed during the time of sending the order), the stops are corrected according to the new data and a new request is sent immediately.
So the knowledge of a trading error (in general - any error) and its proper processing is a prerequisite for the operation of any "normal" program.
Here's the question: if the server returns an order execution error, how do I know about it in order to unblock the ability to resend the order? Again, if OnTrade and OnTradeTransaction are not used.
Very helpful. We will leave the lack of money, because the Expert Advisor should detect this point before sending a trade order and inform the trader with a message (or by some other means). Accordingly, the trade order is not sent at all.
The error message can inform us on whether we should continue trying to send orders at all. For example, if the market is closed, there is no need to resend the request immediately. You should stop the trading for some time (it is determined by the Expert Advisor's developer), and only then send a new request (if the trading signal is still active). If a requote occurs, you can send a new request right away. If there was a mistake in setting the stops (Stop Level or Freeze Level has changed during the time of sending the order), the stops are corrected according to the new data and a new request is sent immediately.
So the knowledge of a trading error (in general - any error) and its correct processing is a necessary condition for the operation of any "normal" program.
If the market is closed, we have to check this before we send the order.
In other cases, the trade order should be resent. Thus, all errors can be divided into two categories:
If an Expert Advisor has received an error of the second type, its actions should be always the same and do not depend on the error type: Namely, it should repeat its trade order hoping that it will be executed this time. Before sending a trade order, the Expert Advisor should control the first type of errors. Therefore, the Expert Advisor has no need to correct its behavior depending on the error type returned in OnTradeTransaction. However, you can notify the user about errors arising in OnTradeTransaction and reset the lock on performing a new trade operation if the previous trade ended up with an error of the second type. In this case, if OnTradeTransaction doesn't occur for some reason, the lock should still be reset by a timeout. Thus, it will not matter if OnTradeTransaction comes or not, just that with OnTradeTransaction repeated orders will be executed at the fastest possible speed.
s.w. FreezeLevel should also be analyzed before the order is sent.