Organising the order cycle - page 11
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
However, it is better not to do so - everything should be in its place.
In the EA timer, we take the list according to the required criteria and when list.Total()>xxx we do what we want.
It turns out that in the old MQL4, where there was no timer, the problem had no solution? Why bother with the timer, when it can be solved in a few lines?
That's exactly what I was looking at.
And my post
And, what is the sense in the real trading that we should continuously chase the loop of orders? Most importantly, it is a waste of time...
To have always up-to-date information on the trading environment, and not to search every time necessary, but to refer to the lists available. And since lists should always be up to date, it is worth taking care to keep them up to date, but efficiently.
After all, if you don't have lists, you will have to search for information when you need it. And not just once per tick. And that's where all the brakes of repeatedly loading the environment will show up.
Although, it is possible to optimise here as well - if we give up control over changes of the environment and fill the lists only when necessary. But then you would lose the ability for the EA to react to user's manual closing/modifying/opening actions.
It turns out that in the old MQL4, where there was no timer, the problem had no solution? Why bother with a timer when it can be solved in a few lines?
When it was impossible to do so, we had to think how to solve it. But it's possible now ;)
To have always up-to-date information on the trading environment, and not have to search every time when necessary, but refer to existing lists. Since lists should always be up-to-date, it is worth taking care to keep them up-to-date at all times, but efficiently.
After all, if you don't have lists, you will have to search for information when you need it. And not just once per tick. And here all slowdowns will appear at repeated loading of environment.
Although, even here can be optimized - if you refuse to control changes of the environment and fill lists only when necessary. But then, you will lose the ability for the EA to react to user actions on manual closing/modifying/opening.
That's the key word"but effective". And what's the deeper meaning of updating the list every millisecond if the list can only change when the next tick arrives? And why not just once per tick? Can an order be closed outside a tick? As I see it, even if there is no tick and the EA sends a command to open/close, i.e., to change the environment, i.e., the list, this action will cause a tick. Or if it isn't, then without a tick caused by something else, the list won't be changed. Isn't it so?
Here's the keyword"but effectively". And what's such a deep sense to update list every millisecond, if list can change only at receipt of next tick? And why not just once per tick? Can an order be closed outside a tick? As I see it, even if there is no tick and the EA sends a command to open/close, i.e., to change the environment, i.e., the list, this action will cause a tick. Or if it isn't, then without a tick caused by something else, the list won't be changed. Isn't it so?
In the tester I run OnTimer(), which creates lists just from OnTick(), but in real life you don't make a difference...
But there a timer is needed not only for creation of lists. All in all - everything we need at once. For now. Further profiling will show the bottlenecks.
That's the key word"but effectively". And what is the deeper meaning of updating the list every millisecond, if the list can only be changed with the arrival of another tick? And why not just once per tick? Can an order be closed outside a tick? As I see it, even if there is no tick and the EA sends a command to open/close, i.e., to change the environment, i.e., the list, this action will cause a tick. Or if it isn't, then without a tick caused by something else, the list won't be changed. Isn't it so?
There is a point in timer bruteforcing if the program works with many symbols - ticks come in at different times.
But it makes no sense to search "not your" list of orders, but the one created by the terminal, which is the reason for the problems that the list is changed by someone else.
There is a point in timer bruteforcing if the program works with many symbols - ticks come in at different times.
But it does not make sense to search "not your own" list of orders, but the list created by the terminal, which is the reason for problems when the list is changed by someone else.
In the case of "not your own" list, there is a total amount of orders that can be stored in a static variable and run the loop to enumerate the environment as it changes. But not every millisecond...
In case the list is "not your own" there is a total number of orders which can be stored in a static variable and run a loop to re-run the environment as it changes. But not every millisecond...
You cannot catch triggering of a pending order in this way.
There is no way of catching the triggering of a pending order in this way.
So we are not talking about catching fleas, i.e. a pending order, we are talking about trying all orders every millisecond.
So it's not about catching fleas, i.e. pending orders, it's about going through all orders every millisecond.
- What do you need a frying pan for?
- For example, to fry eggs.
- It's not about scrambled eggs, it's about the frying pan...