![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Renate, on the gates of Buchenwald was written jedem das Seine
You should not impose your opinion on others. As for the other guys, they don't have the best of them and their decision depends on the parameter they are discussing.
agreed
Divide the balance by the margin of 1 lot.
there will be a risk of 100%.
If you have an order, divide equity by 1 lot of margin, i.e. 100%.
You may have to decrease the spread.
that's why the % risk is included in the formula.
I did not just write the TS-Ru for nothing, like you need to learn to count your grannies...
ps
You won't believe this - the code example is taken from an expo
I only had to open one order of any kind... to get into the market
but I didn't post it...
agree
divide the balance by the margin of 1 lot
it's a 100% risk.
If there are orders, divide equity by 1 lot of margin
I didn't just write to TS-Ru there for nothing, like learn to count your grannies...
And if there are no orders, you can't count by equity?
And if there are no orders, equity cannot be used?
you can
ps-coup in the post.
but I was testing such exposures... calculated on Equi...
it's a slow death.
it's better to do it like CALM
he cut the balance into several parts, like for 4 tries (as far as I remember).
Suppose the risk of 10% of the balance = 10 equal attempts?
calculate on the initial deposit the lot and go, do not recalculate any more
you can
ps-ku in the post.
but i've been testing these exps... with a calculation from equi
it's a slow death.
it is better to do as CALM
he sawed the balance into several parts, attempts like (for 4 as i remember)
Let's say the risk is 10% of the balance = 10 equal attemptsGet it through your head: You don't have to impose your opinion on anyone, much less anyone else's. Why are you talking about some **** who out of those reading this thread knows maybe only you. The man has his own mind, he wants to do what he wants. Why tell him how to lose his deposit faster or slower... That was not and is not part of the question.
Get it through your head: You don't have to impose your opinion on anyone, much less anyone else's. Why are you talking about some **** who, of those reading this thread, may only be known to you? The man has his own mind, he wants to do what he wants. Why tell him how to lose his deposit faster or slower... That was not and is not part of the question.
I'm not imposing anything, it's just a free example.
You asked - from equity can lots be counted?
I said you can, but it's a hassle. I've tried it before.
In such trading conditions it is better to calculate all lots to the minimum leverage so as not to run into a sudden shortage of funds at the most inopportune times.
In this case 1k2
)))
I have a minimum of 1k100
I have a minimum of 1k100 and I don't have a threat of a reduction.
)))
My question was this: "Does OrderCheck() or OrderCalcMargin() take into account the features of leverage "specified approximately" in the specification?"
For which types of features do you have accumulated statistics to reflect them in the calculated value of OrderCalcMargin()? Let me remind you of these feature types: Leverage depends on
1. The symbol
2. Your Polish affiliation
3. Exchange rate of the symbol
4. the current time period - whether it is in one of the news periods
5. Current time - did it hit on a Friday evening
Or is it not? Instead of gathering statistics you cut the possible leverage to the minimum value (in the figure of the 1st post it is 1:2 for BTCUSD, 1:25 for USDBUR) and that's it?
P.S. Your opinion about threats to decrease the leverage may change if you look through the ESMA directive of the European regulator, which comes into force this summer. For example, here https://ru.forexmagnates.com/hochesh-torgovat-kak-ranshe-stan-profi/:
"As a reminder, forex and CFD brokers can only operate normally within the European Union until 1 August 2018. After that, they will have to adapt to substantially stricter conditions. Namely, retail brokers will be able to offer trading with a maximum leverage of 1:30 on major currency pairs, 1:20 on non-major, 1:10 on commodities and non-major indices, 1:5 on equities and only 1:2 on cryptocurrency instruments."
Less than a month to go. Just to remind you, there are a lot of DCs registered in Cyprus and it is now part of the European Union, the ESMA directive applies to it.
My question was: "Does OrderCheck() or OrderCalcMargin() take into account features of leverage that are 'specified approximately' in the specification."
For which types of features do you have accumulated statistics to reflect them in the calculated value of OrderCalcMargin()? Let me remind you of these feature types: Leverage depends on
1. The symbol
2. Your Polish affiliation
3. Exchange rate of the symbol
4. the current time period - whether it is in one of the news periods
5. Current time - did it hit on a Friday evening
Or is it not? Instead of collecting statistics, you cut the possible leverage to the minimum value (in the figure of the 1st message, it is 1:2 for BTCUSD, 1:25 for USDBUR) and that's it?
P.S. Your opinion about threats to decrease the leverage may change if you look through the ESMA directive of the European regulator, which comes into force this summer. For example, here https://ru.forexmagnates.com/hochesh-torgovat-kak-ranshe-stan-profi/:
As a reminder, forex and CFD brokers may operate in the European Union in the normal mode only until August 1, 2018. After that, they will have to adapt to significantly stricter conditions. Namely, retail brokers will be able to offer trading with a maximum leverage of 1:30 on major currency pairs, 1:20 on non-major, 1:10 on commodities and non-major indices, 1:5 on equities and only 1:2 on cryptocurrency instruments.
The rules and trading conditions all spell it out, but it is applied differently, or rather not always
It is not always applied.
brokerage companies and brokers are not discussed here by the rules of this forum.
So you've chosen, it's up to you, adapt.
Your case is one of very few.
Let's wait for the 1st of August.
Maybe it will, then I'll write the code and post it.
The problem will not even be what you write but catching the moment of leverage change.
In the past, we could not catch it without rebooting the terminal.
Now - I don't know, I haven't checked.
The rules and trading conditions all say this, but it is applied differently, or rather not always
Who has what
We do not discuss brokerage companies and brokers according to the forum rules.
So - you have chosen, it's your business and you have to adjust.
Your case is one of very few
Let's wait for the 1st of August.
Maybe it'll hit, then I'll write the code and post it.
The problem won't even be what you write, it will be catching the moment of leverage change.
I could not catch it before without rebooting the terminal.
Now I do not know, I have not checked.
Well, at least something. Did I understand correctly that you cannot find any other way to catch changes of leverage other than restarting the terminal? OrderCalcMargin() doesn't catch these changes, you say? That's exactly the information I was looking for. True, pertaining to "now", and here, unfortunately, there remains uncertainty.
The difference between 1:20 and the usual 1:100 is important for many. And no new code will do, since OrderCalcMargin() does not catch changes of leverage, as you say. We need to modify the OrderCalcMargin() function itself.
And what will the developer say?
Well, that's something. Correct me if I understand that you couldn't find any other way to catch the change of leverage, except for reloading the terminal. OrderCalcMargin() doesn't catch these changes, you say?
Not really.
I had leverage and margin compared on every tick with the previous one, as the leverage floated a lot depending on volatility.
This was 3 years ago.
Trading was active and I had to constantly monitor these parameters.
Later I abandoned leverage (see above for the reason), and tracked only changes of margin conditions, multiple of leverage.
This method proved to be effective.
Unfortunately, the code has not survived, but I will keep my promise.
Therefore, let us go back to the command:
OrderCalcMargin(ORDER_TYPE_SELL,_Symbol,1,BID,Mgn)
let's memorize in the previous
prevMgn=Mgn
and before that let's compare
if(prevMgn/Mgn>1.1 || prevMgn/Mgn<1.1)
and the desired one is in the pocket...
it's time to recalculate the shoulderNot really.
I had leverage and margin compared on every tick with the previous one, as the leverage floated a lot depending on volatility.
This was 3 years ago.
Trading was active and I had to constantly monitor these parameters.
Later I abandoned leverage (see above for the reason), and tracked only changes of margin conditions, multiple of leverage.
This method proved to be effective.
Unfortunately, the code didn't survive, but I'll keep my promise.
Therefore, let us get back to the command:
OrderCalcMargin(ORDER_TYPE_SELL,_Symbol,1,BID,Mgn)
let's memorize in the previous
prevMgn=Mgn
and before that let's compare
if(prevMgn/Mgn>1.1 || prevMgn/Mgn<1.1)
And the desired one is in my pocket...
it's time to recalculate the shoulderYou realise it's not about the code, it's about everyone who can recalculate. But you have added volatility to the list of features, the impact of which you have in fact identified. And if you go further into the forest, you will gather more and more firewood. How to take it into account? The case seems quite hopeless...