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
Trading and quoting sessions won't help to solve the problem?
Unfortunately, no. According to the contract specification, the quotation session starts at 00:00:00 on Monday.
Actually, here Rosh gives the answer that the start of a quotation session does not guarantee the availability of quotes in it. Which is, in principle, understandable.
So far I'm using a "crutch" in the form of the following check:
I'd be grateful if anyone could share a more elegant solution (all multi-currency users must have encountered this).
P.S.
Konstantin Gruzdev offers an elegant variant in his article Implementing the multicurrency mode in MetaTrader 5.
But this variant will not meet the requirements for the Championship.
Yikes... that hit a nerve. :)) The last line was hand-corrected in a forum post, so forgive me. =)
By the way, your code didn't compile either (I forgot to put a closing parenthesis in the last line). :-Р
Besides it's 2-3 times slower (now I've checked it on script), but quality of check is the same. :-Р
Anyway, as long as there's no proper code to determine the significant integer, I'll take Composter's advice: normalize volume to 8 decimal places.
Hopefully there will be no pitfalls.
Reference:
Функцию Sleep() нельзя вызывать из пользовательских индикаторов, так как индикаторы выполняются в интерфейсном потоке и не должны его тормозить.
Is it really, really impossible, or if you really want to, you can, but carefully? :)
Problem with accessing another symbol's data from the indicator.
if there are no ticks)
OrderCheck doesn't help?
Nope. I write a line before the trade:
There's still an error in the log. :(
And what about lot normalization?
Guys, why theorise?
A situation where the lot increment will be greater than the minimum lot is absurd. Well, imagine: min = 0.1, step = 1.0. So, only lots 1.1, 2.1, 3.1, ... are permitted? This is nonsense.
If you're exercising arithmetic and programming, then your options will win. But if we are talking about applied (in the trading sense) programming, then at lot_step > lot_min we must terminate the program with a critical error and urgently change the broker, because it doesn't have enough money even for the salary of a person who would normally configure the server.)
Everything has to be in moderation. My variant has been working on reals for more than 5 years, with different brokers, account types, instruments - never had an error.komposter
Why is it absurd? Let's take a simple example: min_lot = 1.0, min_step = 0.3. The requirements satisfy the principle of "no nonsense" (min_lot >= lot_step). :)
You pass 1.3 lots volume to the normalization function. From it you return 1.2 lots.
The upgraded version will return 1.3. Its steps are "correct": from the minimum lot, not from zero.
Another issue is the presence of "in life" steps other than"1.0, 0.1, 0.01, etc.".
Here, it seems to me, the cost of the issue (loss of performance) is negligible compared to the solution of a possible hypothetical error. IMHO.
After all, it's just more correct to count that way: steps from the minimum lot, not from zero.
Nope. I write a line before I trade:
There is still an error in the logs. :(
Looked at, on championship accounts all instruments are traded at the same time. Register)
TradeCheckResult.retcode != TRADE_RETCODE_DONE
I'm not so sure about this condition...
I don't know if this condition is correct or not:
if(current price == 0.0) return;
komposter
Why is it absurd? Let's take a simple example: minimum lot = 1.0, minimum step = 0.3. The requirements satisfy the principle of "no nonsense" (min_lot >= lot_step). :)
You pass 1.3 lots volume to the normalization function. From it you return 1.2 lots.
The upgraded version will return 1.3. Its steps are "correct": from the minimum lot, not from zero.
Another issue is the presence of "in life" steps other than"1.0, 0.1, 0.01, etc.".
Here, it seems to me, the cost of the issue (loss of performance) is negligible compared to the solution of a possible hypothetical error. IMHO.
After all, it's just more correct to count this way: steps from the minimum lot, not from zero.
"minimum lot = 1.0, minimum step = 0.3" is also absurd. Steps should be a multiple of the minimum lot.
I've already expressed my opinion - in a maths and programming contest, the min_lot subtraction variant will win, it's not needed for real trading.
I don't see the subject for further discussion, everyone has made their own way ;)