Errors, bugs, questions - page 444

 
Interesting:
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:

input int TTL = 10; // Время "жизни" котировки
...
void Trade() {
  ...
  if (TimeCurrent() - SymbolInfoInteger(Instrumet, SYMBOL_TIME) > TTL) return;
  ...
  // Далее отправка торгового приказа на сервер.
}

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.

 
voix_kas:

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.

:)
 
voix_kas:
OrderCheck doesn't help?


 

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)

 
Swan:
OrderCheck doesn't help?

Nope. I write a line before the trade:

if (!OrderCheck(TradeRequest, TradeCheckResult) || (TradeCheckResult.retcode != TRADE_RETCODE_DONE)) return;

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.
Документация по MQL5: Программы MQL5 / Ошибки выполнения
Документация по MQL5: Программы MQL5 / Ошибки выполнения
  • www.mql5.com
Программы MQL5 / Ошибки выполнения - Документация по MQL5
 

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.

 
Is there any ready-made code somewhere that would buy the maximum possible number of lots at the current symbol and price for a given amount of money (e.g. $1234.56 is the only input parameter). Inside there should be all sorts of checks for maximum, minimum volumes, normalization, leverage accounting, sufficiency of funds, etc. etc. The main thing is that the code must make a buy and not bother me with the fact that I have no money (buy as much as I have), that some check failed (make it succeed), that an order is placed, but no buy has occurred (die, but don't return without buying), etc. I understand that somewhere in classes like CTrade this is. But it is not so easy to copy something from there. I want to deal with my own algorithm, not the language of MQL5.
Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация об инструменте
Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация об инструменте
  • www.mql5.com
Стандартные константы, перечисления и структуры / Состояние окружения / Информация об инструменте - Документация по MQL5
 
voix_kas:

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;

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
voix_kas:

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 ;)