With what to replace OnTradeTransaction() in mql4? - page 3
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
If we need a quick solution, then I would place all the tickets to CArrayInt and compare the tickets of open orders with CArrayInt; the Search() method is there; if there is no ticket, we stop comparing CArrayIntwith counters of open orders, reset CArrayInt and write all the tickets into CArrayInt again and set globally described flag MyOnTradeTransaction - this is a sign that the order list has changed - the code will be quite compact
And when we need to catch something more than order loss, that's when we start dancing with diamonds...
Checking OrdersTotal() won't show, for example, activation of a pending order - the number of orders remains the same, so do the tickets... And when we need to catch the fact of order/position modification...
Everything, however, has already been thought out, done and put into the public domain with explanations...
What pluses am I denying? I have only one denial. I want to understand how something works, and if it can only be understood by someone other than my mind, then I am not comfortable using it, and anything I am not comfortable with I deny. I've already told you that you write more letters than I can read for the rest of my life. Don't you take it out on me...
The pros are that no events can get lost. Unlike OnTrade() and OnTradeTransaction(). But you don't believe that such event can get lost... That's why I say - discussion is pointless.
And when you need to catch something more than a missing order, that's where the tambourine starts...
Checking OrdersTotal() will not show activation of a pending order, for example - the number of orders is constant, tickets, too... And when we need to catch modification of an order/position...
Everything, however, has already been thought out, done and made freely available with explanations...
I do not suggest analyzing OrdersTotal, it is not reliable.
You won't be able to track order modifications that way, you will have to write your own class based on CArray or CObj.
I suggested a fast solution, not a fundamental work ;)
The pluses are that we can't lose events.
I'm not suggesting to analyze OrdersTotal, it's not reliable
order modification cannot be tracked that way, you need to write your own class based on CArray or CObj
I suggested a fast solution, not a fundamental work.)
they can if you press the PC reset button .... haven't followed the articles for a long time, but I remember asking about the technique of saving class state to a file in case the terminal is rebooted - is this already implemented?And you can also throw a computer from the balcony - for reliable loss :) And let the roller wait below. Then you can also pour concrete on top :)))
No, it's not implemented - it's not the main thing now. It's almost to the end - it's easier to do everything the same way in one go, rather than splitting it up into different time slots. For me.
No, not implemented - that's not the main thing now. It's almost at the end - it's easier to do everything of the same type in one go, instead of splitting it up into different time slots. For me.
OK, let's wait
But I have turned out to be the opposite - I have already encountered this problem - I did not put the ability to save in the program structure, and started writing saving to a file, very cumbersome everything has turned out.... I've already encountered this problem - I didn't put saving to a file in the program structure - I started writing saving to a file and it turned out to be very cumbersome - I gave up and rewrote most of the code from scratch again - it's a painstaking work, I'll have to analyze the whole source code
I would be grateful if you could provide some reproducible example (without the trade history survey).
I'd be happy to repay your usefulness. I unfortunately have difficulties with forging short working code out of very large and complex code. Which is also very specific (e.g. opens only one pose at a time).
So for Slava I had to post a code skeleton instead of a compilable example.
But I will try to do something, otherwise my conscience will torment me. But not quickly.
PS: I mean I have very low productivity in writing code. I only take it by persistence. And at the same time - super busy in bringing the EA up to speed to run on a real account. I envy your productivity.
OK, let's wait
But I have turned out to be the opposite - I have already encountered this problem - I did not put the ability to save in the program structure, and started writing saving to a file, very cumbersome everything has turned out.... I have already encountered this problem - I didn't put saving to a file in the program structure and started to write saving to a file, and it turned out to be very cumbersome - then I gave up and rewrote most of the code from scratch again - imho, if you plan to save to a file, you must implement it immediately, at least with "stubs", otherwise you will have to collect all you want to save in each class - very laborious work, in fact you will have to analyze the entire source code
The save/load methods are initially declared. And in the base object CObject of the standard library. The implementation of saving to a file in each object of the library can be described for one or two objects. But to write in each article descriptions of methods of saving/loading - will be rather boring reading almost the same "action" from article to article, and simply to omit - is not nice to the reader (and so some people say that it is difficult for them to read such volumes of articles, I think - you too). Therefore - this task for the description in two or three articles closer to the end - at once in one stroke, and not too burdening the reader.
Another thing would be if nothing was described in the articles - then of course it would be necessary at once. It all depends on the specifics of the story and the goals. If the purpose - kodobaza, then all at once, and if the purpose - training articles - then gradually - when the time comes. I have the second option.
The OnTradeTransaction has been mentioned again. There is no problem guaranteeingOnTradeTransaction in case of loss of connection etc., as the terminal will still synchronise the trading environment once the connection is restored. SinceOnTrade is secondary, it means you can rely on them. If the developers themselves didn't make a mistake, but if they removed the clause, it means that everything is OK.
But to fit into each article descriptions of saving/loading methods - will be rather boring reading almost the same "action" from article to article, and just omit - is not nice to the reader (and so some say that they have difficulty reading such volumes of articles, I think - you too). Therefore - this task for the description in two or three articles closer to the end - at once in one fell swoop, and not too burdening the reader.
I did not say that the volume of articles to read is very large, but I wrote that the amount of sources is huge and impossible to figure out how to use it without some kind of help/FAQ
I will wait for the implementation of saving such a large amount of data, it's interesting to see how it will look like
The implementation of saving so much data will have to wait, it will be interesting to see what it will look like
ok