
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
There seems to be no way of knowing in MT4 (without re-connecting) if the leverage on the account has changed.
There seems to be no way in MT4 to know (without re-connecting) if the leverage in the account has changed.
I did it about five years ago. A client's leverage was reduced at certain hours, and it didn't change in the variable AccountInfoInteger(ACCOUNT_LEVERAGE) in any way. And he needed to know about it.
I don't know about the science, but I've decided that there's an account leverage that changes rarely, and there's a symbol leverage that may change several times a day.
I checked it this way:
Sometimes the current calculated leverage by leverageSymb symbol might give 199, 198 instead of 200 (when the leverage is 1:200). Therefore, I had to subtract a certain % from the standard leverage and compare it with this value. The solution above was helpful at the time, it may come in handy.
I did this about five years ago. A client had their leverage reduced at certain hours, and it did not change in any way in the AccountInfoInteger(ACCOUNT_LEVERAGE) variable. And he needed to know about it.
I don't know about the science, but I've decided that there's an account leverage that changes rarely, and there's a symbol leverage that may change several times a day.
I checked it this way:
Sometimes the current calculated leverage by leverageSymb symbol might give 199, 198 instead of 200 (when the leverage is 1:200). Therefore, I had to subtract a certain % from the standard leverage and compare it with this value. The solution above helped then, might come in handy.
Yes, there is no problem with tracking the margin requirements of the symbol. ACCOUNT_LEVERAGE - only reconnect.
It is very common practice to filter the trading history by remembering the required orders in a ticket list. And then SELECT_BY_TICKET on that list.
I've never seen a variant where not a ticket but a position is memorized. Below is a comparison of performance.
We see that the ticket variant loses almost three times in performance.
It can be seen that the ticket variant loses almost three times in performance.
if a position is closed/open, the logic with the ticket will not break, the logic with the position might.
if a position is closed/open, the logic with the ticket will not break, the logic with the position may.
It is only about MODE_HISTORY mode.
Is it theoretically possible that this code will miss some order that existed BEFORE and AFTER the function was called? Or will it count twice.
I.e. what happens to the indexing when an order is deleted or appears during the enumeration?
Or it will count twice.
If we assume default sorting by time or ticket, new orders appear at the end of the list, and logically all are shifted when the oldest ones are deleted.
It turns out when deleting an order from the beginning of the list one of the list can be taken into account twice. It seems easy to work around - just remember the ticket from the previous pass and compare (but still no guarantee).
How to get a pass on the return pass - not figured out
If we assume default sorting by time or ticket, new orders appear at the end of the list, and logically all are shifted when the oldest ones are deleted.
It turns out when deleting an order from the beginning of the list one of the list can be taken into account twice. It seems easy to work around - just remember the ticket from the previous pass and compare (but still no guarantee).
How to get a pass on the return pass - haven't worked it out
Thanks for the detailed reply! So now I'm wondering how to go through ALL the orders at ONE time.